Pulsar period calculator

7 views
Skip to first unread message

Michiel Klaassen

unread,
Nov 21, 2021, 9:31:37 AM11/21/21
to sara-list, camras-forum
Hi All,

Because I have trouble finding a simple way to calculate pulsar periods online and offline, I automated the well known Tempo procedure. 
'Tempo' was developed by Joe Taylor et al. It is a command line procedure typically made to run on Windows. 

Newer versions like Tempo2, PRESTO and Pint are typically intended to be used on Linux, Python.

Many links on the internet pointing to the Taylor pulsar group do not work anymore see; http://pulsar.princeton.edu/

Also there was a calculator on the neutron star website, but it is gone too.

There is an automated method developed by Joe Martin; http://www.k5so.com/documents--and-downloads/download-tempo_calc.html 
 but it does not always work on my old Wxp machines.

That is why this automated procedure was developed. You must give the input variables in the 2pc config file. 
Next start the 2pc.exe, and after two seconds the answer will be written in the 2pc result file.

Procedure:
On the downloads tab of parac.eu the zip tempo file can be found. 

Unzip it and place them in C:\tempo 

I added only two extra files; a config file and an executable.
In 2ptc.cfg you can give all the needed parameters and save them.
Next 2ptc.exe is started and after 2 seconds the result is given in the 2ptc-result.txt file.

The calculated period time can be entered in the pulsar post processing tool 3pt.

This app has been tested to work on Windows-XP, Windows-7 and Windows-10.
(The size of the app is caused by the python dll)
The accuracy is guaranteed until I am 103 years old.

I will make a parac projects tab later.

Best Regards,
Michiel

Michiel Klaassen

unread,
Dec 17, 2021, 5:57:12 AM12/17/21
to sara-list, Peter, Joe Martin, camras-forum
Hi All,

More on the automated Pulsar Tempo program; Part 1.

I have contacted Peter East, and I also had an extensive conversation with Joe Martin about my auto tempo program 2pc.

The accuracy has now been improved by using 15 coefficients compared to the standard 5 coefficients.
The valid day time is extended from 18H to 24H; thus avoiding 'not found solutions'.
Also the end result is determined by interpolating nearest MJD results.

Attached you find the graphs for the difference compared to the python3 script TopoBaryt.py, where the major deviation reduction is seen when going from 5 to 10 and 15 coefficients. The data location set of Peter was used for these graphs.
This topo script has been modified by Peter, but he received it from Wolfgang Herrmann.
The maximum difference is 3e-8 s, and the average difference is 1,2e-8 s over a time period of 24H.
However unknown is how accurate the Topo script itself is, so only a relative deviation can be determined.
There seems to be a difference in the doppler shift result.

The procedure to use the auto tempo tool is as follows.
-Download the tempo51 zip from the parac.eu site
-Put the zip in a new folder in the root; C:\tempo
-extract the zip into that directory; 7-zip; 'extract here'
-edit the 2pc.cfg file; the default values are set to the Dwingeloo radio telescope see Wiki.
    See to it that you enter 12 digits when requested!!
-save it
-run 2pc.exe
-you get the answer in the 2pc-result.txt file.

As a check  you can first run the exe immediately; the pulsar period calculator result should be 0.71456524127s 

The presented method is just an automated procedure of the way Tempo was designed. Full credit is due to Dr. Joseph Taylor et al.
Eset virus scanner did not see any problem with 2pc.exe.
see also

This work will be added to the project list of parac.eu
Be reminded that all my projects are only intended to be used (as an archive) by myself, but other people can use it also if they want. 
I will add more info in another post; Part 2.

Regards.
Michiel


On Tue, Nov 23, 2021 at 8:04 AM 'fasleitung3' via Society of Amateur Radio Astronomers <sara...@googlegroups.com> wrote:
Well, it seems that it not uncommon that Windows Defender reports false positives for Win32/Wactac.B!ml. At least this is what I see reported on the internet.
So it may indeed be a false positive.
Wolfgang


Am Dienstag, den 23.11.2021, 08:57 +0100 schrieb fasleitung3:
Michiel,
There is another issue: I get a warning that your files contain the trojan Win32/Wacatac.B!ml.
This may be a false warning, but I suggest that you check whether this actually the case. Also, I would recommend not to download this application until this is clarified.
Cheers,
Wolfgang


Am Montag, den 22.11.2021, 18:46 +0000 schrieb Michiel Klaassen:
Hi Wolfgang 
Thank you for testing.
Peter East is also testing, I wait for his results also.
Regards,
Michiel


On Mon, Nov 22, 2021 at 9:19 AM 'fasleitung3' via Society of Amateur Radio Astronomers <sara...@googlegroups.com> wrote:
Hi Michiel,
I am afraid there is an issue with your program: If you enter any time between 0 and 12 UTC in the configuration file, the program crashes. It does accept 25 UTC time, so I think there is an error with the time in the configuration file.
Then I found a very signficant difference between the result produced by your program versus a current installation of tempo. Significant means > 10 ppm. I assume there is something outdated in your version. I checked the pulsar ephemeris data for 0329+54 in your version, that is ok and the same I use. The difference must be somewhere else.
Best regards,
Wolfgang
--
--
You received this message because you are subscribed to the Google
Groups "Society of Amateur Radio Astronomers" group.
To post to this group, send email to sara...@googlegroups.com
To unsubscribe from this group, send email to
sara-list-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sara-list?hl=en
---
You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/CAABBjRCbWYK7YhKbHFVm0aK6xOW1PJXO5_3Dai60m7_fKrms9g%40mail.gmail.com.

--
--
You received this message because you are subscribed to the Google
Groups "Society of Amateur Radio Astronomers" group.
To post to this group, send email to sara...@googlegroups.com
To unsubscribe from this group, send email to
sara-list-...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sara-list?hl=en
---
You received this message because you are subscribed to the Google Groups "Society of Amateur Radio Astronomers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sara-list+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sara-list/d7464e9c2ca13a025bfa81f04c602cba96ad458d.camel%40googlemail.com.
tempo-topo-01.JPG
tempo-topo-15c--10c.JPG

Michiel Klaassen

unread,
Dec 17, 2021, 8:54:45 AM12/17/21
to sara-list, Peter, Joe Martin, camras-forum

Part 2

So, I thought that determining the topocentric period was sufficient to extract the pulsar from the noise; I was disappointed.
Filling in all the parameters into the software did not give the best pulsar profile. It gave a good result when I used the very strong signal captured with the Dwingeloo radio telescope.
But even here I could see in the bin over time graph that the bins shifted over time. I had to adjust the period time a little.
This is actually not right. The calculated pulsar period should be exact. 

Well, the 3pt sw can be set to search for the best period time or the best sample rate.
If you are sure the pulsar period is correct, then you can decide to search for the best sample rate; the 3pt program came with the value of 2000100....

When using the rtl_sdr.exe program, it states when activated the 'real' sample rate. So we could use that value. 
It turns out that is not solving the problem neither; it still is too low. 
Also We used several dongles and noted that they all displayed the same 'real' sample rate deviation value of 2000000.52982.
That is not likely, because the tolerances of these simple crystals do vary. 
 
Another way to determine the correct sample rate is by measuring the actual crystal frequency. 
The nominal frequency is 28800000Hz. From this the sample rate is generated (it boils down to this; the actual method is more complex). 
The devision factor for SR of 2MSps is 28800000/2000000= 14.4.

Now we measure the oscillator frequency on the dongle. 
The results are 

Dongle nr  Frequency 
1 RTL         28800300 
2 RTL         28800800
3 RTL         28801400
4 RTL         28800400
5 RTL         28801200
6 RTL         28801000
7 RTL         28801600
8 Nooelec     28800000

When we calculate the sample rate for dongle nr 7: 28801600/14.4=2000111 Sps.
This is exactly the value we also deduced by the automatic searching function of 3pt.


So the conclusion is; when using a RTL dongle with an HC49 shape xtal, then measure the frequency (MF) also.
The corrected sample rates for the selected sample rate will be;

chosen SR real SR 
[Sps]     [Sps]

3200000   MF/9.
2800000   MF/10.2857...
2400000   MF/12.0
2048000   MF/14.0625
2000000   MF/14.4
1000000   MF/28.8


Also temperature drift can add to the problem; so avoid measuring in the start up temperature transient.


Ultimate conclusion:
There are conversion kits to replace the crystal, and with an accurate and temperature stable xtal in later dongle versions, no correction is needed.


Att are the graphs for the S/N results with the two different sample rates; note the S/N values.

see also 


Regards,
Michiel

Multiplot B0329+54 DWRT -2000000.png
starting rtl-exe in dos mode 01.jpg
optimal-search-01.png
Multiplot B0329+54 DWRT -2000111.png
Reply all
Reply to author
Forward
0 new messages