dspsr-users — new features, bug fixes, stable releases, etc.

[dspsr-users] dspsr -K bug

[Willem v. S. <van...@gm...>]

Hi all,

I introduced a bug to the SampleDelay class on 30 Sept 2023, such that its
InputBuffering was effectively disabled and it lost samples on the edge of
every block.

The bug and its fix are described at
https://sourceforge.net/p/dspsr/bugs/111/

If you've updated and compiled dspsr since 30 Sept, and used dspsr -K, then
it is likely that your results will be impacted (e.g. periodic loss of
single pulses at block boundaries).

Sorry about that.  In the not-too-distant future, we'll be migrating dspsr
to a platform that better supports the development of automated testing
pipelines.  This won't catch every bug, but it will help.

Cheers,
Willem

[dspsr-users] dspsr VDIF changes

[Willem v. S. <van...@gm...>]

Hi all,

Today, I checked in some changes to dspsr that enable it to read VDIF
packets that contain signals divided over more than one frequency channel.

Previously, the number of channels encoded in VDIF packet headers was
interpreted as the number of polarizations and it was assumed that only 1
frequency channel was recorded.  Now it is necessary to specify the number
of polarizations in the ASCII header used to supplement the VDIF data file;
this can be done by adding either "NPOL 2" or "NPOL 1" as appropriate.

This commit also includes some changes that enable dspsr to deal with
missing VDIF packets.

With advance apologies for any pipelines that are broken by the new
requirement, please let me know if anything appears to be broken.

Cheers,
Willem

Re: [dspsr-users] dspsr -K bug

[Willem v. S. <van...@gm...>]

P.S. I should have mentioned that this bug affects only baseband data
(samples of the electric field).


On Tue, 12 Sept 2023 at 00:25, Willem van Straten <
van...@gm...> wrote:

> Hi all,
>
> If you use dspsr -K to remove the inter-channel dispersive delays, then
> you may be interested in a bug that was recently discovered and fixed.
> There is also a new application that can fix folded profiles that were
> produced using the buggy dspsr -K.
>
> A more detailed description of the bug, its fix, and the new application
> can be found at
>
> https://sourceforge.net/p/dspsr/bugs/104/
>
> Sorry about the bug; I hope that it has not messed up any of your results.
>
> Sincerely,
> Willem
>
>

[dspsr-users] dspsr -K bug

[Willem v. S. <van...@gm...>]

Hi all,

If you use dspsr -K to remove the inter-channel dispersive delays, then you
may be interested in a bug that was recently discovered and fixed.  There
is also a new application that can fix folded profiles that were produced
using the buggy dspsr -K.

A more detailed description of the bug, its fix, and the new application
can be found at

https://sourceforge.net/p/dspsr/bugs/104/

Sorry about the bug; I hope that it has not messed up any of your results.

Sincerely,
Willem

[dspsr-users] warning for psrchive users on Apple M1 / M2

[Willem v. S. <van...@gm...>]

Hi everyone,

If you start to use psrchive on a new Mac, you may notice error messages
like the following:

inverse_phase maximum iterations exceeded - error=<*yyy.zzz*>us

This is because psrchive uses the "long double" type in various routines
that require more numerical precision than a 64-bit double-precision
floating point can provide; however "long double" is equivalent to "double"
on Apple ARM64

https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms

Until a work-around is implemented, it's best to do your pulsar data
analysis on another machine.

Cheers,
Willem

[dspsr-users] change to digifil that impacts usage

[Willem v. S. <van...@gm...>]

Hi everyone,

I've just checked in a change to digifil that changes the behaviour of the
-2 command line option.

Previously, digifil -2 disabled two-bit excision.  Now digifil -2 behaves
like dspsr -2.  To disable two-bit excision, set the cut-off threshold to
zero; e.g.

digifil -2c0

I hope that this change does not cause too much inconvenience.

Cheers,
Willem

[dspsr-users] changes to dspsr that impact usage

[Willem v. S. <van...@gm...>]

Hi everyone,

I've checked in some fixes to dspsr so that it will continue to operate by
default as it did before the DAT_SCL and DAT_OFFS corrections (specific to
PSRFITS) were added in early 2016.  To enable the corrections, please add
"-scloffs" to the dspsr command line.

Note that the DAT_SCL and DAT_OFFS corrections are not thread-safe;
therefore, dspsr will now abort if "-scloffs" is enabled in multi-threaded
mode.

Because unique values of DAT_SCL and DAT_OFFS are stored for each
polarization, these corrections may be absolutely necessary when analyzing
full-polarization "search mode" data.  If this impacts you (and you care)
please read on below.

Cheers,
Willem

---

If you regularly use dspsr to analyze PSRFITS search mode data, please let
me know what you think about the following three options:

a. make DAT_SCL and DAT_OFFS corrections the default, such that it is
necessary to disable the corrections (e.g. when you want maintain a flat
bandpass);

b. leave the DAT_SCL and DAT_OFFS corrections disabled by default, such
that it is necessary to enable the corrections (e.g. when you want to study
polarization) *[as of today, this is the default behaviour]*; or

c. leave the DAT_SCL and DAT_OFFS corrections disabled by default except
when npol == 4, in which case the corrections are automatically enabled.

Option c. makes things a bit more complicated, which makes (writing and
reading) documentation a bit more necessary; however, it might also make
dspsr behave by default in the most sensible way.

I'm open to suggestions.

Re: [dspsr-users] problems with dspsr on 1-pol DFB search mode data

[Willem v. S. <van...@gm...>]

Hi Marta,

I looked into this problem today and found that the problem appears to be
related to new code added to dspsr in 2016 that applies the scales and
offsets recorded in the PSRFITS file.  Resetting the scale to unity and
offset to zero recovers a plot that is more like old_dspsr.ps

The scales and offsets applied when producing the PSRFITS file likely
flattened the bandpass, which is desireable in many cases, but applying the
scales and offsets when unpacking undoes this goodness.  I plan to add an
option to dspsr so that application of scales and offsets is an option; the
default value for this option will return dspsr to its original behaviour
(not applying scales and offsets when unpacking).

Cheers,
Willem


On Mon, 8 May 2017 at 11:06, Marta Burgay <bu...@oa...>
wrote:

> Dear all,
>
> it looks like the most recent version of dspsr fails to fold search mode
> data recorded with the DFB (at both Parkes and the Sardinia Radio
> Telescope) with 1 polarization.
>
> In attachment you can see an example of what happens folding the same data
> file with the same set of ephemeris with an old version of dspsr
> (installed through PSRsoft, I believe, in 2015) and with the newest
> version.
>
> I did a few tests with SRT data (1-pol 1-bit, 1-pol 2-bits) and PKS data
> (1-pol 1-bit, 4-pol 8-bits) taken in search mode wih the DFB. The latest
> dspsr works fine only on the latter (even though the results are still a
> little better with the old dspsr [pdmp SNR 16 vs 15; first channel
> saturated with the new dspsr]).
>
> I tried both with polyco and predictor and using an ephemeris file or
> giving P and DM directly. Nothing changes.
>
> I'm not sure whether the problem is directly related to dspsr or if it
> depends on psrchive. For SRT data, in fact, I used to install the
> development version of psrchive, before installing dspsr. This solved an
> issue (a warning about an itoa_code not found) that now, with the
> currently available versions of psrchive and dspsr, is back.
>
> Is anyone else having the same problem? Any idea of what can be going on?
>
> Thanks!
>
>         Marta
>
> ---------------------   (> *  ---------------------
> Marta Burgay c/o
> INAF - Osservatorio Astronomico di Cagliari
> via della Scienza 5
> 09047 Selargius (CA)
> Italy
> tel +39 070 71180 249
> fax +39 070 71180 222
>
> ---------------------------------------------------------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> dspsr-users mailing list
> dsp...@li...
> https://lists.sourceforge.net/lists/listinfo/dspsr-users
>

Re: [dspsr-users] .fil format

[William E. <w.h...@cs...>]

Hi Willem.

Thanks for this - it looks promising.

I’m waiting to hear if the computer/software gurus on campus can sort out sigproc.  It’s their job, in a sense, although the software was not new when I used it in 2005/6 and may be out of time now.  Still - others use it, so it should be possible,

Cheers

William


William Edmondson
Honorary Senior Research Fellow
School of Computer Science
University of Birmingham
West Midlands, UK

> On 24 Apr 2018, at 19:19, van...@gm... wrote:
> 
> Hi William,
> 
> In principle, dspsr is able to read WAPP files.  I have not tested this functionality in a long time but I don't see why it should have stopped working.
> 
> The dspsr software package comes with a program called digifil that can process time series data and write out SIGPROC filterbank format.
> 
> Combined, these two features mean that, in principle, digifil could be used to convert from WAPP to SIGPROC filterbank format, with the following caveat. The data will be converted from WAPP binary format to floating point numbers, and these floating point numbers will then be requantized using some specified number of bits per sample before writing out SIGPROC binary format; therefore, the output data will not be a binary equivalent representation of the input data.
> 
> For WAPP, this would have always been the case regardless of how the file conversion is performed (WAPP stores a time series of ACFs and SIGPROC stores a time series of PSDs).
> 
> I hope that this helps you to decide on how to proceed.
> 
> Cheers,
> Willem
> 
> 
> On 24 April 2018 at 23:21, William Edmondson <w.h...@cs... <mailto:w.h...@cs...>> wrote:
> Hi folks.
> 
> I’m currently using PRESTO to process some data from Parkes.
> I have lots of data from Arecibo in WAPP format which I also need to process.  PRESTO doesn’t handle those files.
> 
> I need to convert the WAPP format to .fil
> 
> I’ve used sigproc in the past, but there are compilation problems at Birmingham (where the data are held, and the processing software is compiled for me on the multiprocessor research cluster).  I’m not sure the problems can be resolved but I’m trying!  If that can be made to work I’d use sigproc to convert the format and then use PRESTO.
> 
> Scott Ransom suggested dspsr could convert WAPP files to .fil (for subsequent use with PRESTO).
> 
> Does dspsr offer that file conversion?  Or would I be obliged to do folding etc with dspsr?
> 
> But before I go there….  I need to know if it sensible to ask the software folk managing my compute resource to compile dspsr.
> 
> Comments please.
> 
> Thanks.
> 
> William.
> 
> And by way of ps this provides some background: 
> 
> https://www.cambridge.org/core/journals/international-journal-of-astrobiology/article/the-utilization-of-pulsars-as-seti-beacons/5F880137A2B60CF81EB775FACD9ADB66 <https://www.cambridge.org/core/journals/international-journal-of-astrobiology/article/the-utilization-of-pulsars-as-seti-beacons/5F880137A2B60CF81EB775FACD9ADB66>
> 
> If anyone wants a copy of that paper but can’t readily get it from CUP then email me.
> 
> 
> 
> 
> William Edmondson
> Honorary Senior Research Fellow
> School of Computer Science
> University of Birmingham
> West Midlands, UK
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
> _______________________________________________
> dspsr-users mailing list
> dsp...@li... <mailto:dsp...@li...>
> https://lists.sourceforge.net/lists/listinfo/dspsr-users <https://lists.sourceforge.net/lists/listinfo/dspsr-users>
> 
> 

Re: [dspsr-users] .fil format

[Willem v. S. <van...@gm...>]

Hi William,

In principle, dspsr is able to read WAPP files.  I have not tested this
functionality in a long time but I don't see why it should have stopped
working.

The dspsr software package comes with a program called digifil that can
process time series data and write out SIGPROC filterbank format.

Combined, these two features mean that, in principle, digifil could be used
to convert from WAPP to SIGPROC filterbank format, with the following
caveat. The data will be converted from WAPP binary format to floating
point numbers, and these floating point numbers will then be requantized
using some specified number of bits per sample before writing out SIGPROC
binary format; therefore, the output data will not be a binary equivalent
representation of the input data.

For WAPP, this would have always been the case regardless of how the file
conversion is performed (WAPP stores a time series of ACFs and SIGPROC
stores a time series of PSDs).

I hope that this helps you to decide on how to proceed.

Cheers,
Willem


On 24 April 2018 at 23:21, William Edmondson <w.h...@cs...>
wrote:

> Hi folks.
>
> I’m currently using PRESTO to process some data from Parkes.
> I have lots of data from Arecibo in WAPP format which I also need to
> process.  PRESTO doesn’t handle those files.
>
> I need to convert the WAPP format to .fil
>
> I’ve used sigproc in the past, but there are compilation problems at
> Birmingham (where the data are held, and the processing software is
> compiled for me on the multiprocessor research cluster).  I’m not sure the
> problems can be resolved but I’m trying!  If that can be made to work I’d
> use sigproc to convert the format and then use PRESTO.
>
> Scott Ransom suggested dspsr could convert WAPP files to .fil (for
> subsequent use with PRESTO).
>
> Does dspsr offer that file conversion?  Or would I be obliged to do
> folding etc with dspsr?
>
> But before I go there….  I need to know if it sensible to ask the software
> folk managing my compute resource to compile dspsr.
>
> Comments please.
>
> Thanks.
>
> William.
>
> And by way of ps this provides some background:
>
> https://www.cambridge.org/core/journals/international-
> journal-of-astrobiology/article/the-utilization-of-
> pulsars-as-seti-beacons/5F880137A2B60CF81EB775FACD9ADB66
>
> If anyone wants a copy of that paper but can’t readily get it from CUP
> then email me.
>
>
>
>
> William Edmondson
> Honorary Senior Research Fellow
> School of Computer Science
> University of Birmingham
> West Midlands, UK
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> dspsr-users mailing list
> dsp...@li...
> https://lists.sourceforge.net/lists/listinfo/dspsr-users
>
>

[dspsr-users] .fil format

[William E. <w.h...@cs...>]

Hi folks.

I’m currently using PRESTO to process some data from Parkes.
I have lots of data from Arecibo in WAPP format which I also need to process.  PRESTO doesn’t handle those files.

I need to convert the WAPP format to .fil

I’ve used sigproc in the past, but there are compilation problems at Birmingham (where the data are held, and the processing software is compiled for me on the multiprocessor research cluster).  I’m not sure the problems can be resolved but I’m trying!  If that can be made to work I’d use sigproc to convert the format and then use PRESTO.

Scott Ransom suggested dspsr could convert WAPP files to .fil (for subsequent use with PRESTO).

Does dspsr offer that file conversion?  Or would I be obliged to do folding etc with dspsr?

But before I go there….  I need to know if it sensible to ask the software folk managing my compute resource to compile dspsr.

Comments please.

Thanks.

William.

And by way of ps this provides some background: 

https://www.cambridge.org/core/journals/international-journal-of-astrobiology/article/the-utilization-of-pulsars-as-seti-beacons/5F880137A2B60CF81EB775FACD9ADB66

If anyone wants a copy of that paper but can’t readily get it from CUP then email me.




William Edmondson
Honorary Senior Research Fellow
School of Computer Science
University of Birmingham
West Midlands, UK

Re: [dspsr-users] problems with dspsr on 1-pol DFB search mode data

[Marta B. <bu...@oa...>]

Dear all,

note that the problem seems to be with 1-POL data, and not necessarily 
with 1-BIT data (I have not done extensive testing and I don't think I 
have anything 4-pol 1-bit to double-check, but dspsr has the same 
issue also with 1-pol 2-bit data).

As I was saying to Scott, both presto's prepfold and a previous version of 
dspsr do not have any isue with any DFB search mode data. I don't think, 
hence, that that the problem is with changes in the data format.

Cheers,

 	Marta

On Tue, 9 May 2017, John Reynolds wrote:

> Hi all,
>
>> I know that the 1-bit format changed sometime over the last couple
>> years.  The bit ordering in each byte was reversed (i.e. going from LSB
>> to MSB first, or vise versa).  I doubt that that would make this issue,
>
> All Parkes DFB search mode data taken since 2008-9 are 'MS bit first'. Prior 
> to this it was mostly the other way around, I believe.
>
> In 2013 there was a change made to write 1-bit data as CFITSIO type 'B' 
> (byte) rather than type 'X' (bit) . All other bit depths were already being 
> written as type 'B'. This change should have been transparent to the user and 
> was tested by Dick at the time, including with dspsr, and given a clean bill 
> of health. (The change was found to be required to eliminate spurious extra 
> rows being added to the end of the datafile in 1-bit mode).
>
> The last change of any kind made to the DFB code was Sep 2015 and should not 
> have had any affect on the recorded data.
>
> Cheers,
> John Reynolds
>
> On Tue, 9 May 2017, Scott Ransom wrote:
>
>> Hey Marta,
>> 
>> I know that the 1-bit format changed sometime over the last couple
>> years.  The bit ordering in each byte was reversed (i.e. going from LSB
>> to MSB first, or vise versa).  I doubt that that would make this issue,
>> but it is hard to tell.
>> 
>> Have you tried folding the data with PRESTO?
>> 
>> Scott
>> 
>> On 05/05/2017 03:45 AM, Marta Burgay wrote:
>>> Dear all,
>>> 
>>> it looks like the most recent version of dspsr fails to fold search mode
>>> data recorded with the DFB (at both Parkes and the Sardinia Radio
>>> Telescope) with 1 polarization.
>>> 
>>> In attachment you can see an example of what happens folding the same
>>> data file with the same set of ephemeris with an old version of dspsr
>>> (installed through PSRsoft, I believe, in 2015) and with the newest
>>> version.
>>> 
>>> I did a few tests with SRT data (1-pol 1-bit, 1-pol 2-bits) and PKS data
>>> (1-pol 1-bit, 4-pol 8-bits) taken in search mode wih the DFB. The latest
>>> dspsr works fine only on the latter (even though the results are still a
>>> little better with the old dspsr [pdmp SNR 16 vs 15; first channel
>>> saturated with the new dspsr]).
>>> 
>>> I tried both with polyco and predictor and using an ephemeris file or
>>> giving P and DM directly. Nothing changes.
>>> 
>>> I'm not sure whether the problem is directly related to dspsr or if it
>>> depends on psrchive. For SRT data, in fact, I used to install the
>>> development version of psrchive, before installing dspsr. This solved an
>>> issue (a warning about an itoa_code not found) that now, with the
>>> currently available versions of psrchive and dspsr, is back.
>>> 
>>> Is anyone else having the same problem? Any idea of what can be going on?
>>> 
>>> Thanks!
>>>
>>>     Marta
>>> 
>>> ---------------------   (> *  ---------------------
>>> Marta Burgay c/o
>>> INAF - Osservatorio Astronomico di Cagliari
>>> via della Scienza 5
>>> 09047 Selargius (CA)
>>> Italy
>>> tel +39 070 71180 249
>>> fax +39 070 71180 222
>>> ---------------------------------------------------
>>> 
>>>
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dspsr-users mailing list
>>> dsp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dspsr-users
>>> 
>> 
>> -- 
>> Scott M. Ransom            Address:  NRAO
>> Phone:  (434) 296-0320               520 Edgemont Rd.
>> email:  sr...@nr...             Charlottesville, VA 22903 USA
>> GPG Fingerprint: A40A 94F2 3F48 4136 3AC4  9598 92D5 25CB 22A6 7B65
>>
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> dspsr-users mailing list
>> dsp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dspsr-users
>> 
>

---------------------   (> *  ---------------------
Marta Burgay c/o
INAF - Osservatorio Astronomico di Cagliari
via della Scienza 5
09047 Selargius (CA)
Italy
tel +39 070 71180 249
fax +39 070 71180 222
---------------------------------------------------

Re: [dspsr-users] problems with dspsr on 1-pol DFB search mode data

[Marta B. <bu...@oa...>]

Hi Scott,

it works just fine with presto (if you add -noscales -nooffsets) as well 
as with the previous dspsr (for sure the version from 2014 compiled with 
psrchive devel version).

 	M.

On Mon, 8 May 2017, Scott Ransom wrote:

> Hey Marta,
>
> I know that the 1-bit format changed sometime over the last couple years. 
> The bit ordering in each byte was reversed (i.e. going from LSB to MSB first, 
> or vise versa).  I doubt that that would make this issue, but it is hard to 
> tell.
>
> Have you tried folding the data with PRESTO?
>
> Scott
>
> On 05/05/2017 03:45 AM, Marta Burgay wrote:
>> Dear all,
>> 
>> it looks like the most recent version of dspsr fails to fold search mode
>> data recorded with the DFB (at both Parkes and the Sardinia Radio
>> Telescope) with 1 polarization.
>> 
>> In attachment you can see an example of what happens folding the same
>> data file with the same set of ephemeris with an old version of dspsr
>> (installed through PSRsoft, I believe, in 2015) and with the newest
>> version.
>> 
>> I did a few tests with SRT data (1-pol 1-bit, 1-pol 2-bits) and PKS data
>> (1-pol 1-bit, 4-pol 8-bits) taken in search mode wih the DFB. The latest
>> dspsr works fine only on the latter (even though the results are still a
>> little better with the old dspsr [pdmp SNR 16 vs 15; first channel
>> saturated with the new dspsr]).
>> 
>> I tried both with polyco and predictor and using an ephemeris file or
>> giving P and DM directly. Nothing changes.
>> 
>> I'm not sure whether the problem is directly related to dspsr or if it
>> depends on psrchive. For SRT data, in fact, I used to install the
>> development version of psrchive, before installing dspsr. This solved an
>> issue (a warning about an itoa_code not found) that now, with the
>> currently available versions of psrchive and dspsr, is back.
>> 
>> Is anyone else having the same problem? Any idea of what can be going on?
>> 
>> Thanks!
>>
>>     Marta
>> 
>> ---------------------   (> *  ---------------------
>> Marta Burgay c/o
>> INAF - Osservatorio Astronomico di Cagliari
>> via della Scienza 5
>> 09047 Selargius (CA)
>> Italy
>> tel +39 070 71180 249
>> fax +39 070 71180 222
>> ---------------------------------------------------
>> 
>>
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> 
>> 
>> 
>> _______________________________________________
>> dspsr-users mailing list
>> dsp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dspsr-users
>> 
>
> -- 
> Scott M. Ransom            Address:  NRAO
> Phone:  (434) 296-0320               520 Edgemont Rd.
> email:  sr...@nr...             Charlottesville, VA 22903 USA
> GPG Fingerprint: A40A 94F2 3F48 4136 3AC4  9598 92D5 25CB 22A6 7B65
>

---------------------   (> *  ---------------------
Marta Burgay c/o
INAF - Osservatorio Astronomico di Cagliari
via della Scienza 5
09047 Selargius (CA)
Italy
tel +39 070 71180 249
fax +39 070 71180 222
---------------------------------------------------

Re: [dspsr-users] problems with dspsr on 1-pol DFB search mode data

[John R. <Joh...@cs...>]

Hi all,

> I know that the 1-bit format changed sometime over the last couple
> years.  The bit ordering in each byte was reversed (i.e. going from LSB
> to MSB first, or vise versa).  I doubt that that would make this issue,

All Parkes DFB search mode data taken since 2008-9 are 'MS bit first'. 
Prior to this it was mostly the other way around, I believe.

In 2013 there was a change made to write 1-bit data as CFITSIO type 'B' 
(byte) rather than type 'X' (bit) . All other bit depths were already 
being written as type 'B'. This change should have been transparent to the 
user and was tested by Dick at the time, including with dspsr, and given a 
clean bill of health. (The change was found to be required to eliminate 
spurious extra rows being added to the end of the datafile in 1-bit mode).

The last change of any kind made to the DFB code was Sep 2015 and should 
not have had any affect on the recorded data.

Cheers,
John Reynolds

On Tue, 9 May 2017, Scott Ransom wrote:

> Hey Marta,
>
> I know that the 1-bit format changed sometime over the last couple
> years.  The bit ordering in each byte was reversed (i.e. going from LSB
> to MSB first, or vise versa).  I doubt that that would make this issue,
> but it is hard to tell.
>
> Have you tried folding the data with PRESTO?
>
> Scott
>
> On 05/05/2017 03:45 AM, Marta Burgay wrote:
>> Dear all,
>>
>> it looks like the most recent version of dspsr fails to fold search mode
>> data recorded with the DFB (at both Parkes and the Sardinia Radio
>> Telescope) with 1 polarization.
>>
>> In attachment you can see an example of what happens folding the same
>> data file with the same set of ephemeris with an old version of dspsr
>> (installed through PSRsoft, I believe, in 2015) and with the newest
>> version.
>>
>> I did a few tests with SRT data (1-pol 1-bit, 1-pol 2-bits) and PKS data
>> (1-pol 1-bit, 4-pol 8-bits) taken in search mode wih the DFB. The latest
>> dspsr works fine only on the latter (even though the results are still a
>> little better with the old dspsr [pdmp SNR 16 vs 15; first channel
>> saturated with the new dspsr]).
>>
>> I tried both with polyco and predictor and using an ephemeris file or
>> giving P and DM directly. Nothing changes.
>>
>> I'm not sure whether the problem is directly related to dspsr or if it
>> depends on psrchive. For SRT data, in fact, I used to install the
>> development version of psrchive, before installing dspsr. This solved an
>> issue (a warning about an itoa_code not found) that now, with the
>> currently available versions of psrchive and dspsr, is back.
>>
>> Is anyone else having the same problem? Any idea of what can be going on?
>>
>> Thanks!
>>
>>     Marta
>>
>> ---------------------   (> *  ---------------------
>> Marta Burgay c/o
>> INAF - Osservatorio Astronomico di Cagliari
>> via della Scienza 5
>> 09047 Selargius (CA)
>> Italy
>> tel +39 070 71180 249
>> fax +39 070 71180 222
>> ---------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> dspsr-users mailing list
>> dsp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dspsr-users
>>
>
> -- 
> Scott M. Ransom            Address:  NRAO
> Phone:  (434) 296-0320               520 Edgemont Rd.
> email:  sr...@nr...             Charlottesville, VA 22903 USA
> GPG Fingerprint: A40A 94F2 3F48 4136 3AC4  9598 92D5 25CB 22A6 7B65
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> dspsr-users mailing list
> dsp...@li...
> https://lists.sourceforge.net/lists/listinfo/dspsr-users
>

Re: [dspsr-users] problems with dspsr on 1-pol DFB search mode data

[Scott R. <sr...@nr...>]

Hey Marta,

I know that the 1-bit format changed sometime over the last couple 
years.  The bit ordering in each byte was reversed (i.e. going from LSB 
to MSB first, or vise versa).  I doubt that that would make this issue, 
but it is hard to tell.

Have you tried folding the data with PRESTO?

Scott

On 05/05/2017 03:45 AM, Marta Burgay wrote:
> Dear all,
>
> it looks like the most recent version of dspsr fails to fold search mode
> data recorded with the DFB (at both Parkes and the Sardinia Radio
> Telescope) with 1 polarization.
>
> In attachment you can see an example of what happens folding the same
> data file with the same set of ephemeris with an old version of dspsr
> (installed through PSRsoft, I believe, in 2015) and with the newest
> version.
>
> I did a few tests with SRT data (1-pol 1-bit, 1-pol 2-bits) and PKS data
> (1-pol 1-bit, 4-pol 8-bits) taken in search mode wih the DFB. The latest
> dspsr works fine only on the latter (even though the results are still a
> little better with the old dspsr [pdmp SNR 16 vs 15; first channel
> saturated with the new dspsr]).
>
> I tried both with polyco and predictor and using an ephemeris file or
> giving P and DM directly. Nothing changes.
>
> I'm not sure whether the problem is directly related to dspsr or if it
> depends on psrchive. For SRT data, in fact, I used to install the
> development version of psrchive, before installing dspsr. This solved an
> issue (a warning about an itoa_code not found) that now, with the
> currently available versions of psrchive and dspsr, is back.
>
> Is anyone else having the same problem? Any idea of what can be going on?
>
> Thanks!
>
>     Marta
>
> ---------------------   (> *  ---------------------
> Marta Burgay c/o
> INAF - Osservatorio Astronomico di Cagliari
> via della Scienza 5
> 09047 Selargius (CA)
> Italy
> tel +39 070 71180 249
> fax +39 070 71180 222
> ---------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> dspsr-users mailing list
> dsp...@li...
> https://lists.sourceforge.net/lists/listinfo/dspsr-users
>

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sr...@nr...             Charlottesville, VA 22903 USA
GPG Fingerprint: A40A 94F2 3F48 4136 3AC4  9598 92D5 25CB 22A6 7B65

[dspsr-users] problems with dspsr on 1-pol DFB search mode data

[Marta B. <bu...@oa...>]

Dear all,

it looks like the most recent version of dspsr fails to fold search mode 
data recorded with the DFB (at both Parkes and the Sardinia Radio 
Telescope) with 1 polarization.

In attachment you can see an example of what happens folding the same data 
file with the same set of ephemeris with an old version of dspsr 
(installed through PSRsoft, I believe, in 2015) and with the newest 
version.

I did a few tests with SRT data (1-pol 1-bit, 1-pol 2-bits) and PKS data 
(1-pol 1-bit, 4-pol 8-bits) taken in search mode wih the DFB. The latest 
dspsr works fine only on the latter (even though the results are still a 
little better with the old dspsr [pdmp SNR 16 vs 15; first channel 
saturated with the new dspsr]).

I tried both with polyco and predictor and using an ephemeris file or 
giving P and DM directly. Nothing changes.

I'm not sure whether the problem is directly related to dspsr or if it 
depends on psrchive. For SRT data, in fact, I used to install the 
development version of psrchive, before installing dspsr. This solved an 
issue (a warning about an itoa_code not found) that now, with the 
currently available versions of psrchive and dspsr, is back.

Is anyone else having the same problem? Any idea of what can be going on?

Thanks!

 	Marta

---------------------   (> *  ---------------------
Marta Burgay c/o
INAF - Osservatorio Astronomico di Cagliari
via della Scienza 5
09047 Selargius (CA)
Italy
tel +39 070 71180 249
fax +39 070 71180 222
---------------------------------------------------

[dspsr-users] Introduction

[Adam B. <ad...@sk...>]

Hi dspsr users,


I'm an engineer working at SKA SA and I'm interested in using the DSPSR
package for pulsar search and timing on our infrastructure. I'm looking for
some pulsar data and some guidance in getting up to speed with psrchive,
dspsr and psrdata?

I have installed the PSRCIVE and DSPSR, however when running "make check"
on PSRCHIVE I receive a buffer overflow in test_template when parsing
psrheader.fits

core dump as follows

#0  0x00007fc1f8a343a5 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fc1f8a37b0b in __GI_abort () at abort.c:92
#2  0x00007fc1f8a6dd63 in __libc_message (do_abort=2, fmt=0x7fc1f8b5d39e
"*** %s ***: %s terminated\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007fc1f8af84f7 in __GI___fortify_fail (msg=0x7fc1f8b5d335 "buffer
overflow detected") at fortify_fail.c:32
#4  0x00007fc1f8af7410 in __GI___chk_fail () at chk_fail.c:29
#5  0x00007fc1f8af7739 in __fgets_chk (
    buf=0x7fffc1edc330 "COMMENT   FITS (Flexible Image Transport System)
format defined in Astronomy and\n\a/",
    size=81, n=<optimized out>, fp=0x7ae040) at fgets_chk.c:58
#6  0x0000000000405f57 in parse_template(char const*, bool) ()
#7  0x0000000000405b16 in main ()

Any help would be greatly appreciated.


Regards

Adam Barta




-- 
*Adam Barta*
c: +27 72 105 8611
e: ad...@sk...
w: www.ska.ac.za

[dspsr-users] DSPSR moved to Git

[Willem v. S. <van...@gm...>]

Hi everyone,

DSPSR development is now managed using Git.  Big thanks to Jonathan
Khoo for carefully shepherding the code to its new home.

Instructions for Git access are posted at

http://dspsr.sourceforge.net/current

If you have previously copied the dspsr Git repository, then you can
merge with the lastest version using the following commands

git fetch
git merge origin/master

Happy processing!

Cheers,
Willem

[Dspsr-users] DSPSR moving to Git

[Willem v. S. <van...@gm...>]

Hi everyone,

On Friday 13 April, DSPSR development will no longer be managed using
CVS and the code repository will be moved to Git.

If you have read-only access to the DSPSR repository (i.e. you are not
a developer), then you can simply delete the old dspsr/ directory and
clone the new.  Instructions for Git access will be posted at

http://dspsr.sourceforge.net/current

If you are a developer and you have outstanding modifications in a
module that was checked out using CVS, then you may want to check
these into the repository before 13 April.  After this date, changes
will have to be manually merged with the version maintained in the Git
repository.

Cheers,
Willem