GammaSphere DAQ - User contributions [en]

DAQ system

2026-01-21T15:04:02Z

Moberling:

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+These devices are used both by data acquisition and by control & monitoring
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-}
{| class="wikitable"
|+These devices are used by control & monitoring only.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| piserver1 || 192.168.203.154 || Collector Boot Host
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-}
{| class="wikitable"
|+These devices are used by directly logging into them to control power to the VME crates, network switches and terminal servers.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu-south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-}
{| class="wikitable"
|+These devices are used by directly logging into them to connect to the console ports of IOC01 through IOC12.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts-south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-}
{| class="wikitable"
|+These devices are associated with the liquid nitrogen subsystem.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|-
| ln2con || 192.168.203.148 || Linux computer that lnfill boots from
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The Gammasphere DAQ system consists of VME crates, IOC Modules, Digitizers and Trigger Modules. The original "analog" implementation of Gammasphere using the VXI modules used a charge-integrating ADC methodology and did not continuously digitize the data from the detectors. The Digital Gammasphere system (2010s) introduced the digitizers as a replacement for the charge-integrating ADC functions of the VXI modules and replaces the "analog" system's trigger by a new trigger system, requiring a redesign of the DAQ. The later "Gammasphere Upgrade" project (2019-2023) that resulted in the SBX, preamp and collector box hardware did not materially affect the DAQ but replaced all of the remaining control, monitoring and power distribution functions of the VXI system allowing removal of the VXI system and associated cable plant.

Each digitizer in the system consists of 10 channels, but should be conceptualized as a pair of two ''sub-digitizers'' consisting of five channels each. There are two types of digitizers: master and slave. A pair of channels in a master digitizer receives signals from the Ge center and BGO sum from a single Gammasphere detector, while a channel-pair in the slave digitizer receives signals from the Ge side and BGO pattern. All channels in all digitizers run continuously. There are two types of digitizers (master and slave) as well as two types of triggers (master and router).

When discriminator logic within the digitizer firmware marks edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. Similarly the trigger modules have FIFO buffers that store information each time a trigger acceptance message is issued to the digitizers. The IOC scans the FIFOs of all modules to see if there is data to read out through a series of programs named inLoop, outLoop and MiniSender. If data is available, the inLoop program reads it and stores the data read into memory buffers. Program outLoop verifies the integrity of the buffers and then hands control of the buffers to the MiniSender program. A separate program running on a different computer called “gtReceiver” sends messages to each IOC's MiniSender program when it is capable of receiving data. The MiniSender program of each IOC, in response to requests from gtReceiver, then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then stores the data received to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

DAQ system

2026-01-21T15:01:07Z

Moberling:

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+These devices are used both by data acquisition and by control & monitoring
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-}
{| class="wikitable"
|+These devices are used by control & monitoring only.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-}
{| class="wikitable"
|+These devices are used by directly logging into them to control power to the VME crates, network switches and terminal servers.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu-south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-}
{| class="wikitable"
|+These devices are used by directly logging into them to connect to the console ports of IOC01 through IOC12.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts-south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-}
{| class="wikitable"
|+These devices are associated with the liquid nitrogen subsystem.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|-
| ln2con || 192.168.203.148 || Linux computer that lnfill boots from
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The Gammasphere DAQ system consists of VME crates, IOC Modules, Digitizers and Trigger Modules. The original "analog" implementation of Gammasphere using the VXI modules used a charge-integrating ADC methodology and did not continuously digitize the data from the detectors. The Digital Gammasphere system (2010s) introduced the digitizers as a replacement for the charge-integrating ADC functions of the VXI modules and replaces the "analog" system's trigger by a new trigger system, requiring a redesign of the DAQ. The later "Gammasphere Upgrade" project (2019-2023) that resulted in the SBX, preamp and collector box hardware did not materially affect the DAQ but replaced all of the remaining control, monitoring and power distribution functions of the VXI system allowing removal of the VXI system and associated cable plant.

Each digitizer in the system consists of 10 channels, but should be conceptualized as a pair of two ''sub-digitizers'' consisting of five channels each. There are two types of digitizers: master and slave. A pair of channels in a master digitizer receives signals from the Ge center and BGO sum from a single Gammasphere detector, while a channel-pair in the slave digitizer receives signals from the Ge side and BGO pattern. All channels in all digitizers run continuously. There are two types of digitizers (master and slave) as well as two types of triggers (master and router).

When discriminator logic within the digitizer firmware marks edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. Similarly the trigger modules have FIFO buffers that store information each time a trigger acceptance message is issued to the digitizers. The IOC scans the FIFOs of all modules to see if there is data to read out through a series of programs named inLoop, outLoop and MiniSender. If data is available, the inLoop program reads it and stores the data read into memory buffers. Program outLoop verifies the integrity of the buffers and then hands control of the buffers to the MiniSender program. A separate program running on a different computer called “gtReceiver” sends messages to each IOC's MiniSender program when it is capable of receiving data. The MiniSender program of each IOC, in response to requests from gtReceiver, then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then stores the data received to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

Updating Firmware in Digitizers and Triggers

2024-02-22T23:56:10Z

Moberling:

==New Procedure for DGS:==
[https://wiki.anl.gov/wiki_gsdaq/images/d/d7/Flash_Maintenance_Instructions_20240222.odt Flash_Maintenance_Instructions_20240222.odt]

==Old Procedure for DFMA, DUB, DXA:==
# Log into dgs account on dgs1
# Get the *.bin from directory /Digitizer/MAIN_FPGA/Work11_DGS
## We have 4 flavors, MSTR_digitizer, SLAVE_digitizer, trigger_top and router_top
# copy to /home/dgs/tmadden/DGSDigFirmware or /home/dgs/tmadden/DGSTrigFirmware
## You can rename file to reflect the date compiled e.g. MSTR_digitizer_2020722.bin
# cd /home/dgs/tmadden/swWork/workspace/epicsClient/src
# issue following: java -classpath jca-2.3.5.jar:caj-1.1.9.jar:fpgasender.jar plotControl 
# copy and paste below

epics.epics_init(); 
var fn0=new String("/home/dgs/tmadden/swWork/workspace/epicsClient/src/asynRecords.txt"); 
var fn1=new String("/home/dgs/tmadden/retfile.bin"); 
epics.connectPVs(fn0); 
var digware=new String("/home/dgs/tmadden/DGSDigFirmware/MSTR_digitizer_20200722.bin"); 
var slvware=new String("/home/dgs/tmadden/DGSDigFirmware/SLAVE_digitizer_20200602.bin"); 
var mastware=new String("/home/dgs/tmadden/DGSTrigFirmware/trigger_top_20160626.bin"); 
var routware=new String("/home/dgs/tmadden/DGSTrigFirmware/router_top_20160601.bin"); 

-'''NOTE: Need to define add current name of master, slave digitizer bin files and trigger & router bin file names''' 
-'''NOTE: If bin file name is wrong, program will still try to flash and result will be yellow fever.''' 
-'''NOTE: The asynRecords.txt file defines the active crates. If you get a missing PV during setup, edit this file or better yet, make a new one and assign it instead.''' 

If you get this far, you are now ready to flash the individual digitizers

* To flash digitizer type epics.sendFpga(digware, fn1, 1, 0,1, 1, 1);
** This line sends the firmware file defined in digware to the board.
** The args of the function are defined as: epics.sendFgga(Firmwarename, ret file name, Crate num, Board num, erase, program, verify)
** IN the above function, we send digware to crate 1, board 0 and erase, program and verify the fpga.
* To Update the FPGA so it runs the new firmware. ON the dig boards there is a PV called GLBL:DIG:config_main_fpga that will reconfigure ALL digitizer FPGAs in DGS. This is convenient.
* To update a single FPGA, say in VME1, we use VME01:DIG1:config_main_fpga. Simple write a 1 to these PVs to reconfig the FPGAs.
* For the Trigger crate, a power cycle is needed but power cycle also works for digitizers too. 

==Below are cut and paste commands to use with DFMA ==
=== Trigger and Routers ===
'''For master trigger''' 
epics.sendFpga(mastware, fn1, 0, 0,1, 1, 1); 

'''For routers''' 
epics.sendFpga(routware, fn1, 0, 1,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 2,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 3,1, 1, 1); 

'''add these for FMA''' 

epics.sendFpga(routware, fn1, 0, 4,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 5,1, 1, 1); 

===DGS Digitizers===
'''master digitzers''' 
epics.sendFpga(digware, fn1, 1, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 1, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 2, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 2, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 3, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 3, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 4, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 4, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 5, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 5, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 6, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 7, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 7, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 8, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 8, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 9, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 9, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 10, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 11, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 11, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 12, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 12, 2, 1,1,0); 
'''slave digitzers''' 
epics.sendFpga(slvware, fn1, 1, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 1, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 2, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 2, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 3, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 3, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 4, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 4, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 5, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 5, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 6, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 7, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 7, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 8, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 8, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 9, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 9, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 10, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 11, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 11, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 12, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 12, 3, 1,1,0); 

===For Non-Slave Configuration (FMA):===
 
epics.sendFpga(digware, fn1, 1, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 3, 1,1,1);

Updating Firmware in Digitizers and Triggers

2024-02-22T23:54:04Z

Moberling:

==New Procedure for DGS:==
[https://wiki.anl.gov/wiki_gsdaq/images/d/d7/Flash_Maintenance_Instructions_20240222.odt Flash_Maintenance_Instructions_20240222.odt]

==Some more notes about flashing digitizers or triggers:==
# Log into dgs account on dgs1
# Get the *.bin from directory /Digitizer/MAIN_FPGA/Work11_DGS
## We have 4 flavors, MSTR_digitizer, SLAVE_digitizer, trigger_top and router_top
# copy to /home/dgs/tmadden/DGSDigFirmware or /home/dgs/tmadden/DGSTrigFirmware
## You can rename file to reflect the date compiled e.g. MSTR_digitizer_2020722.bin
# cd /home/dgs/tmadden/swWork/workspace/epicsClient/src
# issue following: java -classpath jca-2.3.5.jar:caj-1.1.9.jar:fpgasender.jar plotControl 
# copy and paste below

epics.epics_init(); 
var fn0=new String("/home/dgs/tmadden/swWork/workspace/epicsClient/src/asynRecords.txt"); 
var fn1=new String("/home/dgs/tmadden/retfile.bin"); 
epics.connectPVs(fn0); 
var digware=new String("/home/dgs/tmadden/DGSDigFirmware/MSTR_digitizer_20200722.bin"); 
var slvware=new String("/home/dgs/tmadden/DGSDigFirmware/SLAVE_digitizer_20200602.bin"); 
var mastware=new String("/home/dgs/tmadden/DGSTrigFirmware/trigger_top_20160626.bin"); 
var routware=new String("/home/dgs/tmadden/DGSTrigFirmware/router_top_20160601.bin"); 

-'''NOTE: Need to define add current name of master, slave digitizer bin files and trigger & router bin file names''' 
-'''NOTE: If bin file name is wrong, program will still try to flash and result will be yellow fever.''' 
-'''NOTE: The asynRecords.txt file defines the active crates. If you get a missing PV during setup, edit this file or better yet, make a new one and assign it instead.''' 

If you get this far, you are now ready to flash the individual digitizers

* To flash digitizer type epics.sendFpga(digware, fn1, 1, 0,1, 1, 1);
** This line sends the firmware file defined in digware to the board.
** The args of the function are defined as: epics.sendFgga(Firmwarename, ret file name, Crate num, Board num, erase, program, verify)
** IN the above function, we send digware to crate 1, board 0 and erase, program and verify the fpga.
* To Update the FPGA so it runs the new firmware. ON the dig boards there is a PV called GLBL:DIG:config_main_fpga that will reconfigure ALL digitizer FPGAs in DGS. This is convenient.
* To update a single FPGA, say in VME1, we use VME01:DIG1:config_main_fpga. Simple write a 1 to these PVs to reconfig the FPGAs.
* For the Trigger crate, a power cycle is needed but power cycle also works for digitizers too. 

==Below are cut and paste commands to use with DGS or DFMA ==
=== Trigger and Routers ===
'''For master trigger''' 
epics.sendFpga(mastware, fn1, 0, 0,1, 1, 1); 

'''For routers''' 
epics.sendFpga(routware, fn1, 0, 1,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 2,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 3,1, 1, 1); 

'''add these for FMA''' 

epics.sendFpga(routware, fn1, 0, 4,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 5,1, 1, 1); 

===DGS Digitizers===
'''master digitzers''' 
epics.sendFpga(digware, fn1, 1, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 1, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 2, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 2, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 3, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 3, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 4, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 4, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 5, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 5, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 6, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 7, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 7, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 8, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 8, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 9, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 9, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 10, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 11, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 11, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 12, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 12, 2, 1,1,0); 
'''slave digitzers''' 
epics.sendFpga(slvware, fn1, 1, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 1, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 2, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 2, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 3, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 3, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 4, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 4, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 5, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 5, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 6, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 7, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 7, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 8, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 8, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 9, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 9, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 10, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 11, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 11, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 12, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 12, 3, 1,1,0); 

===For Non-Slave Configuration (FMA):===
 
epics.sendFpga(digware, fn1, 1, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 3, 1,1,1);

File:Flash Maintenance Instructions 20240222.odt

2024-02-22T23:51:53Z

Moberling:

Building the Entire System

2024-02-22T00:35:47Z

Moberling: /* Compiling the Code used in the VME IOCs */

A multi-stage make is required to build the .munch files for the IOCs. Munch files are raw binary executable for the MVME5500's VxWorks operating system generated by a cross compiler. The cross compiler resides on machine con6, a Sun Solaris machine. This machine has no internal hard disk, it connects to the network file server. This means files ''can'' be copied willy-nilly but that doesn't mean they ''should'' be. Yes, physicists, I speak to you. '''DO NOT TOUCH /dk/fs2/dgs/global_sanbox EVER. NO, NEVER!!'''

=== How Gammasphere VME IOCs boot ===
Each of the VME processors in Gammasphere (VME01 - VME12) are embedded processors running the VxWorks operating system, version 5.5. For some history see https://www.windriver.com/blog/vxworks-past-and-future, but don't allow the maximally stupid concept of "upgrading" to enter your mind. Everything in the system is specifically dependent and designed for VxWorks version 5.5, and if you change that, you have contracted to spend the next 5 years of your life attempting to rebuild everything for ZERO functional gain.

When the VxWorks processors are powered on they first boot from an onboard boot loader PROM. If one has access to a console terminal window the data in the PROM may be viewed or edited. The PROM specifies the IP address, user name and location of the boot script that the VME processor will load and execute after the initial PROM boot, and also the location of the VxWorks image.

==== Boot Host for VME processors ====
Machine DGS1 is the boot host for VME processors. The VxWorks OS image and the boot scripts for all the VME processors are located on machine DGS1, starting at the folder /global/ioc.

==== Shared File System ====
Machine DGS1 and other machines in the data room use a shared file server. The /global folder on many machines is actually just a symbolic link. /global, ''depending upon which machine you log into'', may be one of '''''THREE''''' different locations on the file server:

* Machines running a 64-bit OS like Rocky Linux will map /global to /dk/fs2/dgs/global_64.
* Machines running Scientific Linux 6 (e.g. DGS1) will map /global to /dk/fs2/dgs/global_32.
* One specific machine (CON6), critical to the maintenance of the system, maps /global to /dk/fs2/dgs/global_sandbox.

== File Structure of Boot Host DGS1 ==

The root of the boot host is the folder '''/global/ioc''' that has subfolders

* bin
* boot
* db
* dbd
* dgsSoftIOC
* epics
* FW_Maint (Will be deprecated in the '''imminent''' future)
* gui

The places that change when the system is rebuilt are the '''bin''', '''boot''' and '''gui''' areas.

=== Compiling the Code used in the VME IOCs ===
# ssh -XY dgs@dgs1
# cd /dk/fs/dgs/global_sandbox/devel/dgsDrivers/dgsDriverApp/src
# ./Export_SVN_ParameterFiles_from_dgs1.sh
# ssh -XY dgs@con6
# cd /global/devel/dgsDrivers
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# cd ../dgsIoc
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# Log out of con6
# Log into dgs1 as dgs
# cd /global/ioc/bin/vxWorks-ppc604_long
# ./CopyNewMunch.sh

=== Ensuring EPICS databases are up to date ===
# ssh -XY dgs@dgs1
# cd /global/ioc/db
# ./Export_SVN_Databases.sh
# You will have to reboot all the VME IOCs to load the new databases.
# You will have to stop and restart the Soft IOC to load the new databases

=The entire sequence from spreadsheet to boot=

==Spreadsheet general path==

* Checkout or update a local working copy of https://svn.inside.anl.gov/repos/psg/CodeGeneratingSpreadsheetsGeneric onto a Windows PC.
* Make any modifications to the spreadsheet needed to update desired functionality in firmware, EPICS, C structs, etc.
* There are different projects for every kind of FPGA/board.
* After the spreadsheet is run then the entire folder tree for the project must be committed to SVN.

===Spreadsheet outputs===

A spreadsheet for the digitizer or the master trigger or the router trigger has a folder '''SS_output''' that contains all of its output products.
The output products of interest for the Area IV data acquisition systems are

====files for rebuilding the VxWorks driver====
* asyn<boardtype>Params.c
* asyn<boardtype>Params.h

The Solaris machine 'con6' has no 'svn' program installed on it, so some other machine that has 'svn' must be used to pull the files down.
This is done by

* cd /dk/fs2/dgs/global_sandbox/devel/dgsDrivers/dgsDriverApp/src
* ./Export_Parameter_Files_from_dgs1.sh

After you have exported the parameter files, then compile as described above.

Once you have successfully compiled, then you must go to the '''boot machine''' (e.g. DGS1) and do the following:

* cd /global/ioc/bin/vxWorks-ppc604_long
* ./CopyNewMunch.sh

====files used by the VME IOCs to generate PVs====
* <boardtype>Registers.template
* <boardtype>User.template
* A series of 'VMExx.db' files (however many were defined in the system definition file of the spreadsheet)

These files must be exported from SVN to the folder on the boot host machine (e.g. dgs1) for use by the VME IOC processor
during the boot of that specific processor. This is done by

* cd /global/ioc/db
* ./Export_SVN_Databases.sh

====files used by the Soft IOC (run on the host machine, e.g. DGS1)====
* JustGlobals.db

This file must be exported from SVN to the folder on the boot host machine where the Soft IOC resides. This is done by

* cd /global/ioc/dgsSoftIOC/db
* ./Export_SVN_SoftIOC_Database.sh

Building the Entire System

2024-02-20T02:17:51Z

Moberling: /* Compiling the Code used in the VME IOCs */

A multi-stage make is required to build the .munch files for the IOCs. Munch files are raw binary executable for the MVME5500's VxWorks operating system generated by a cross compiler. The cross compiler resides on machine con6, a Sun Solaris machine. This machine has no internal hard disk, it connects to the network file server. This means files ''can'' be copied willy-nilly but that doesn't mean they ''should'' be. Yes, physicists, I speak to you. '''DO NOT TOUCH /dk/fs2/dgs/global_sanbox EVER. NO, NEVER!!'''

=== How Gammasphere VME IOCs boot ===
Each of the VME processors in Gammasphere (VME01 - VME12) are embedded processors running the VxWorks operating system, version 5.5. For some history see https://www.windriver.com/blog/vxworks-past-and-future, but don't allow the maximally stupid concept of "upgrading" to enter your mind. Everything in the system is specifically dependent and designed for VxWorks version 5.5, and if you change that, you have contracted to spend the next 5 years of your life attempting to rebuild everything for ZERO functional gain.

When the VxWorks processors are powered on they first boot from an onboard boot loader PROM. If one has access to a console terminal window the data in the PROM may be viewed or edited. The PROM specifies the IP address, user name and location of the boot script that the VME processor will load and execute after the initial PROM boot, and also the location of the VxWorks image.

==== Boot Host for VME processors ====
Machine DGS1 is the boot host for VME processors. The VxWorks OS image and the boot scripts for all the VME processors are located on machine DGS1, starting at the folder /global/ioc.

==== Shared File System ====
Machine DGS1 and other machines in the data room use a shared file server. The /global folder on many machines is actually just a symbolic link. /global, ''depending upon which machine you log into'', may be one of '''''THREE''''' different locations on the file server:

* Machines running a 64-bit OS like Rocky Linux will map /global to /dk/fs2/dgs/global_64.
* Machines running Scientific Linux 6 (e.g. DGS1) will map /global to /dk/fs2/dgs/global_32.
* One specific machine (CON6), critical to the maintenance of the system, maps /global to /dk/fs2/dgs/global_sandbox.

== File Structure of Boot Host DGS1 ==

The root of the boot host is the folder '''/global/ioc''' that has subfolders

* bin
* boot
* db
* dbd
* dgsSoftIOC
* epics
* FW_Maint (Will be deprecated in the '''imminent''' future)
* gui

The places that change when the system is rebuilt are the '''bin''', '''boot''' and '''gui''' areas.

=== Compiling the Code used in the VME IOCs ===
# ssh -XY dgs@con6
# cd /global/devel/dgsDrivers/dgsDriverApp/src
# ./Export_SVN_ParameterFiles.sh
## Or run ./Export_SVN_ParameterFiles_from_dgs1.sh from /dk/fs/dgs/global_sandbox/devel/dgsDrivers/dgsDriverApp/src
# cd /global/devel/dgsDrivers
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# cd ../dgsIoc
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# Log out of con6
# Log into dgs1 as dgs
# cd /global/ioc/bin/vxWorks-ppc604_long
# ./CopyNewMunch.sh

=== Ensuring EPICS databases are up to date ===
# ssh -XY dgs@dgs1
# cd /global/ioc/db
# ./Export_SVN_Databases.sh
# You will have to reboot all the VME IOCs to load the new databases.
# You will have to stop and restart the Soft IOC to load the new databases

=The entire sequence from spreadsheet to boot=

==Spreadsheet general path==

* Checkout or update a local working copy of https://svn.inside.anl.gov/repos/psg/CodeGeneratingSpreadsheetsGeneric onto a Windows PC.
* Make any modifications to the spreadsheet needed to update desired functionality in firmware, EPICS, C structs, etc.
* There are different projects for every kind of FPGA/board.
* After the spreadsheet is run then the entire folder tree for the project must be committed to SVN.

===Spreadsheet outputs===

A spreadsheet for the digitizer or the master trigger or the router trigger has a folder '''SS_output''' that contains all of its output products.
The output products of interest for the Area IV data acquisition systems are

====files for rebuilding the VxWorks driver====
* asyn<boardtype>Params.c
* asyn<boardtype>Params.h

The Solaris machine 'con6' has no 'svn' program installed on it, so some other machine that has 'svn' must be used to pull the files down.
This is done by

* cd /dk/fs2/dgs/global_sandbox/devel/dgsDrivers/dgsDriverApp/src
* ./Export_Parameter_Files_from_dgs1.sh

After you have exported the parameter files, then compile as described above.

Once you have successfully compiled, then you must go to the '''boot machine''' (e.g. DGS1) and do the following:

* cd /global/ioc/bin/vxWorks-ppc604_long
* ./CopyNewMunch.sh

====files used by the VME IOCs to generate PVs====
* <boardtype>Registers.template
* <boardtype>User.template
* A series of 'VMExx.db' files (however many were defined in the system definition file of the spreadsheet)

These files must be exported from SVN to the folder on the boot host machine (e.g. dgs1) for use by the VME IOC processor
during the boot of that specific processor. This is done by

* cd /global/ioc/db
* ./Export_SVN_Databases.sh

====files used by the Soft IOC (run on the host machine, e.g. DGS1)====
* JustGlobals.db

This file must be exported from SVN to the folder on the boot host machine where the Soft IOC resides. This is done by

* cd /global/ioc/dgsSoftIOC/db
* ./Export_SVN_SoftIOC_Database.sh

Main Page

2023-03-29T20:21:17Z

Moberling:

These are the official Wikipedia pages for the now digital and previously analog Gammasphere Data Acquisition systems (GS DAQs). Procedures for running the DAQs and the data format will be documented here, as well as details of the hardware and processes of Gammasphere.

The GS DAQ serves the [http://www.phy.anl.gov/gammasphere/ Gammasphere detector array], located at the [http://www.phy.anl.gov/atlas ATLAS accelerator], home of the [http://www.phy.anl.gov/atlas/caribu/ CAlifornium Rare Isotope Breeder Upgrade (CARIBU)].

Contact mailto:torben@anl.gov for comments on, and write access to, these wiki pages.
==[[Understanding Gammasphere Interactively]]==
* [[Interactive Image Map]]

* [[Gammasphere]]

* [[DGS Commander EDM Screens]]

* [[DAQ system]]

==[[Digital Gammasphere Upgrade Project]]==
* [[Digital Gammasphere Upgrade Project]]

* [[User Guides for Experiments]]

* [[Advanced User Guides]]

* [[Expert Documentation]]

==[[Original Content prior to the ''Gammasphere Upgrade Project'']]==
The intro section contains an interactive block diagram of Gammasphere system prior to the ''2021 Upgrade Project''.

* [[Intro]]

* [[Analog Gammasphere]]

* [[List of experimental runs/analysis]]

* [[Typical DGS run procedures]]

* [[Analysis codes]]

* [[Some problems and their solutions]]

* [[Beginner Guide to Digitizer Firmware]]

* [[Computers and networks]]

* [[Receivers/GEBMerge/GEBsort]]

* [[Raspberry Pi camera use]]

* [[Handeling removable disks under ESATA]]

* [[Data formats]]

* [[Triggers and digitizers]]

* [[Digitizer Tester]]

* [[The DGS/DFMA EPICS Implementation]]

* [[Firmware documentation]]

* [[Tim Madden software documentation]]

* [[JohnSandbox]]

==Hardware==
Gammasphere is comprised of many different kinds of hardware for function and data acquisition. Below is an outline of the different hardware that is detailed in separate pages. It also contains details of the Liquid Nitrogen (LN) system.
* [[DAQ system]]
* [[Gammasphere Detectors]]
* [[Detector Signals]]
* [[Liquid Nitrogen]]
* [[LN system]]
* [[Preamplifier]]
* [[The Slope Box]]
* [[The Slope Box Extension]]
* [[SBX Power Board]]
* [[The Pickoff Card]]
* [[DAQ Power Supply]]
* [[Collector Box]]
* [[VME Crates]]
* [[Digitizers]]
* [[Triggers]]
* [[Digitizer IOCs|IOC]]

== Support Devices ==
* [[Network Accessible Power Control Units of DGS]]
* [https://wiki.anl.gov/wiki_gsdaq/images/4/40/MyRIAD_User_Manaual.pdf MyRIAD_User_Manaual]
* [https://wiki.anl.gov/wiki_gsdaq/images/1/16/MyRIAD_Abridged_User_Notes.pdf MyRIAD_Abridged_User_Notes]
* [[Attempts at Inventory]]
* [[CrateAndBoardMapping]]

==On-Site Experts Only==

* [[Building the Entire System]]

* [[Linking Systems Together]]

* [[Updating Firmware in Digitizers and Triggers]]

* [[IOC Code Design]]

==Contact List==

Mike Carpenter, mailto:carpenter@anl.gov

John Anderson, mailto:jta@anl.gov

Michael Oberling, mailto:moberling@anl.gov

Torben Lauritsen, mailto:torben@anl.gov

Darek Seweryniak, mailto:seweryniak@anl.gov

Amel Korichi, mailto:korichi@csnsm.in2p3.fr

{{Template:Standard Footer}}