#131 Question regarfing header of filterbank, possible incompatible
Hello, I am triying to use dspsr to fold a filterbank file and getting the singlepulse file for each rotation but I am getting this message:
*** buffer overflow detected ***: dspsr terminated
I have been reading and I suspect it could be some incompatibility in the header of the file. The observation was recorded using two ETTUS boards and summing 2 polarization, obtaining the total intensity as the recorded data.
If I read the header with "readfile" from PRESTO, this is what I get:
1: From the SIGPROC filterbank file 'ds8192_J0835-4510_A2_20260206_223701.fil':
Telescope = IAR2
Source Name = J0835-4510_A2
Backend = Ettus-B205
Obs Date String = 2026-02-07T01:37:04
MJD start time = 61078.06740740740497
RA J2000 = 08:35:20.6115
RA J2000 (deg) = 128.835881208333
Dec J2000 = -45:10:34.8751
Dec J2000 (deg) = -45.1763541944444
Tracking? = True
Azimuth (deg) = 0
Zenith Ang (deg) = 0
Number of polns = 2 (summed)
Sample time (us) = 146.285714285714
Central freq (MHz) = 1428.4375
Low channel (MHz) = 1400.875
High channel (MHz) = 1456
Channel width (MHz) = 0.875
Number of channels = 64
Total Bandwidth (MHz) = 56
Beam = 1 of 1
Beam FWHM (deg) = 1.000
Spectra per subint = 480
Spectra per file = 13631488
Time per subint (sec) = 0.0702171428571
Time per file (sec) = 1994.09195886
bits per sample = 32
bytes per spectra = 256
samples per spectra = 64
bytes per subint = 122880
samples per subint = 30720
zero offset = 0
Invert the band? = False
bytes in file header = 387
I suspect that there could be an incompatibility between the parameters of the headers and the one that dspsr would expect. I read somewhere that it could be that dspsr would check the next equation:
nchans X npol X nbits, and that it would expect this to be the bytes per spectra.
In this case the incompatibilty would arise from the expected number of spectra (64x2x4=512) against the number of spectra specified (256). I am not sure if that is actually the source of the abortion in dspsr.
I was hoping you could tell me if that is probably the source of the incompatibility, and which would be the recomended way to:
- change the filterbank file to be compatible (should I just rewrite the header as a 256 byte file?)
- which would be the way to write the header when we are recording the data so the configuration would be correctly interpreted by dspsr.
Thanks in advance.
Hi Susana,
Thanks for the bug report. To help with debugging, could you please try the following?
digihdr ds8192_J0835-4510_A2_20260206_223701.fil(cut and paste the output to this thread)dspsr -V <all other command line options> ds8192_J0835-4510_A2_20260206_223701.fil(and attach the very verbose output to this ticket)Cheers,
Willem
Hello Willem,
thanks for the fast reply. Here are the outputs of 1. and 2. I also uploaded the file I'm using for this test to Google Drive. Please request access so I can grant you permission to download it: https://drive.google.com/drive/folders/1dZC9w4r6sCoba9RCQ9DkUstHQW3-xV4t?usp=sharing
One thing that could came handy is the following: we can fold the files using PRESTO, and we pretty much can use any rutine of it (I haven't encoutered an incompatibility). I was now trying to fold using dspsr, because I wanted to extract the phase information of each single pulse in a pulsar rotation. I was not able to do that. Altough, we are able to use PSRCHIVE in the products of folding with PRESTO, such as the folded profile stored in the .pfd files, which we can aling using
pam -e. We also can get the TOAS from each file, and we do have the telescope added to TEMPO2. So the issue seams to be with loading the filterbank file itself with dspsr.digihdr ds8192_J0835-4510_A2_20260206_223701.filThis is what I get:
Thank you for this extra information, which provides a good clue. The last line of output from dspsr before the buffer overflow is detected ("dsp::File::create testing S2") indicates that the S2 file format test code has a bug leading to the buffer overflow.
I'll try to fix this, but in the meantime you can work around the problem by removing "s2" from the
bandends.listtext files in your top-level DSPSR build directory.In fact, I suggest that you remove most of the file formats listed in this file unless you need them. For example, a "minimal"
backends.listmight look like:fits sigproc vdif
This would enable DSPSR to read PSRFITS, SigProc "filterbank", and files containing VDIF packets (by default, DSPSR can also read "DADA" files: https://dspsr.sourceforge.net/manuals/dspsr/dada.shtml).
Please let me know if removing "s2" fixes the problem - ¡Suerte!
And thanks for the file! I think that I've fixed the S2 bug in
Thanks Willem!
I had an issue trying to make the formats listed minimal, as the folder of dspsr appeared as executable for some reason in my installation, instead of just a folder. So I'll try the solution and let you know if it is working for me.
Thanks again!