While debugging, it is often neccessary to dump the contents of a packet to the terminal or some other output stream. The Packet objects provide two different dump functions, one just called "dump", the other one "gdump()", a "generic dump". The former presents the data in an easily readable and to some extent interpreted fashion. For this to yield accurate results, the dump function must make some assumptions about the integrity of the data. Since this is not always the case, the gdump function provides a strict hexadecimal (or decimal, if so desired) dump of the data, without making any assumptions about the meaning of certain fields within the data stream.

In order to illustrate this, we replace the original "identify()" call with

  if (p) 
    {
      // yes, we got the packet, and we ask it now to get channel 57 for us
      int channel57 = p->iValue(57);
      p->gdump();
      cout << "-----------" << endl;
      p->dump();
      cout << "Channel 57 is " << channel57 << endl;
 

The first "generic dump" gives the following output:

Packet  8002   985  0 (Unformatted)  408 (IDPBSC_DCM0)
    0 |      ffff        4     1039       25 
    4 |         2        4       1d       1b 
    8 |        1f     1fff     2dd7     3ddc 
    c |      4dd6     5dd9     1fff     2dcc 
< --- lines deleted --- >
  3c8 |      5fff     5f00     5f00     5f00 
  3cc |      5f00     5f00     5f00     5f00 
  3d0 |      5f00     ed77     9201 

As you can see, this is just a straight hex dump of the data, and it will not try to interpret anything. This will work even if the data are corrupt internally; you will just see the numbers one after the other. Also, you can "gdump" packets which don't have a decoding routine (or, in general, a packet class which can deal with the data) yet (for example, while you are in the process of developing one.

The gdump function takes tw optional parameters, a "dump style" parameter which can be "HEXADCIMAL" (the default) or "DECIMAL". So you could write

      p->gdump(DECIMAL);

The definitions of the cnstants come with the "packet.h" include file.

The second "dump" statement gives you a somewhat interpreted version of the data. within the data of this particular EmCal packet, there are some user words, AMU cell information, and a lot more, and the dump will try to list the data in a meaningful way:

Packet  8002   985  0 (Unformatted)  408 (IDPBSC_DCM0)
  Start marker word :     ffff
  Detector id:               4
  Event number:           1039
  Module address:           25
  Flag Word:                 2
  Beam Clock Counter:        4
  AMU cell 1:               1d
  AMU cell 2:               1b
  AMU cell 3:               1f
  Userword 0      1fff
  Userword 1      2fff
  Userword 2      3fff
  Userword 3      4fff
  Userword 4      5fff
  Userword 5      1fff
  Userword 6      2fff
  Userword 7      3fff
  Long. Parity word       4fff
    0 |      1fff     2dd7     3ddc     4dd6     5dd9 
    1 |      2dd7     3ddc     4dd6     5dd9     1fff 
    2 |      3ddc     4dd6     5dd9     1fff     2dcc 
    3 |      4dd6     5dd9     1fff     2dcc     3dcb 
    4 |      5dd9     1fff     2dcc     3dcb     4dc7 
< --- lines deleted --- >
  141 |      29c7     391d     49b7     5912     173e 
  142 |      391d     49b7     5912     173e     29ca 
  143 |      49b7     5912     173e     29ca     3924 

So the not-generic dump function, which knows about the inner structure of the data, lists most of the quantities by name. The 144 lines of hex dump give the 5 data words from each of the 144 channels inside this packet.

Note: For many packets there is no "special" dump function available yet. In this case, the dump function just calls the generic gdump function.