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
>