Using RTL2832 Dongles for Dispersion Measurement

It may be possible to do dispersion measurements on selected pulsars using relatively inexpensive RTL2832 dongle devices.  The following analysis is inspired by the experiments conducted by Guillermo Gancio (IAR) using two RTL2832 dongle devices. The results of using PRESTO (specifically 'prepfold') to analyse Guillermo's real data are compared with the results obtained by analysing a number of simulated data files.

NOTE: the information presented here is not the last word - it is a presentation of analyses which invites challenges and/or corrections. 

Analysis of Real Data from a Dual RTL2832 Dongle Configuration

Guillermo has provided two RTL_SDR I/Q raw data files of an observation of Vela (DM = 68) by a hardware configuration consisting of two RTL2832 dongle devices reading RF signals from a single 150 MHz IF channel. The two dongles were tuned to frequencies within the IF channel separated by 13 MHz which translate to front-end frequencies of 1423MHZ and 1410 MHz. The two I/Q data files were combined into one SIGPROC 'filterbank' .FIL format file suitable for analysis by the 'prepfold' module in the PRESTO suite.  The result of the analysis using the following command line...

prepfold -noxwin -n 64 -nsub 2 -p 0.08939 -dm 68.0 <filename.fil>

...is shown here (click on thumbnail to open larger view in new window - close that window to return here)...

gg_vela_2chan13

It should be clear from examination of this result that the observation returns a poor estimate of DM. i.e., 56.217 versus the correct DM of 68.  There are a number of possible reasons for this. e.g. - misalignment of the timing between the two channels (leading to an error in the measured delay between them), incorrect formatting of the filterbank data, basic limit to the precision/accuracy of the measurement algorithm for the given data or a combination thereof. 

The creation of simulated filterbank format files and subsequent analysis sheds some light on the possible culprit(s).

Analysis of Simulated Data of Various RTL2832 Dongle Configurations

The first simulated file was created from a different single channel observation of Vela.   A second channel was created by time-shifting a copy of the single channel observation by the amount determined by a DM of 68 and observation frequencies 1410 MHz and 1423 MHz.  These two files were then combined into one filterbank format file.

This first simulated file mimics the real observation - i.e., two channels separated by 13 MHz at frequencies of 1410 MHz and 1423 MHz.  The time offset applied is 2.58 ms which is the timing difference that would be evident in real data for Vela (DM = 68) between those two frequencies.  The command line parameters are as before...

prepfold -noxwin -n 64 -nsub 2 -p 0.08939 -dm 68.0 <filename.fil>

...and the result is shown here...

Here we see that, although the delay between the two channels for this simulated data is what it should be (2.58 ms) for the real observation above, the poor result is replicated, i.e., 56.221 versus the correct DM of 68.  This indicates that the poor result in the real data analysis is not alone due to a mistiming between the channels. It can be noted by comparing the two DM graphs (bottom-centre of graphic) that they indicate a fairly coarse resolution for the DM axis.  Note also that the values (56.217 and 56.221) are the values on the graph corresponding to the left hand edge of the coarse DM 'blocks' - a case of being in-accurate to 3 decimal places...

At this point it appears that the poor result is due to the coarse DM resolution on the horizontal axis. An assertion has been made by this author that a better estimate could be made by improving the DM resolution via the provision of more channels for the same end-to-end bandwidth.  To illustrate this a simulated filterbank file was created which has 10 channels spread over the 13 MHz space between 1423 MHz and 1410 MHz.   The command line parameter '-nsub' has been adjusted for 10 channels...

prepfold -noxwin -n 64 -nsub 10 -p 0.08939 -dm 68.0 <filename.fil>

...and the result is shown here...

It can be seen that, indeed, the horizontal DM axis resolution has been improved markedly.  However, this improvement in resolution reveals another issue - the underlying DM curve has a fairly broad nose with a wide range of DMs with similar values. Any noise on the DM values can result in the highest peak being at a DM value over a wide range.  This is illustrated quite nicely by the peak DM value now being found at 33.465.  So, an increase in resolution has worsened the measurement 'accuracy'.  Of course, the 'better' accuracy of the two channel results is due to the serendipitous placement of the coarse DM steps rather than real accuracy. It is timely to note that the noise across the broad nose of the DM curve for these set of conditions is likely to be higher when analysing data with a poorer S/N, resulting in even more uncertainty in the result.

We can 'sharpen' the nose of the DM curve and get closer to the correct DM value of 68 by spreading the 10 channels over a wide total frequency span as this series shows for spans of 13 MHz, 18 MHz and 50 MHz...

...however, while the 10 channel 50 MHz span curve has a sharper peak, noise in the peak gives an error in the result (74.887 = +10% error) greater than the result for 10 channel 18 MHz (66.455 = -2.3% error) .  In order to get results within a few % of the correct value a much wider frequency span is needed as any errors in pulse phase calculations are a smaller fraction of the larger differential delay over the frequency span observed.

The resultant curve for a configuration of 10 channels spread across 180 MHz is shown below...

Here the peak is sharp enough that any noise on the DM measurement rapidly drops away either side of the peak so any errors caused by the noise on the measurement will only cause a returned value with a small difference from the correct value (67.618 = -0.6% error).

A configuration where 10 RTL2832 dongles devices are covering a total frequency span of the order of 200 MHz is not a simple proposition. It precludes using a single IF at a lower frequency as it is difficult to implement the necessary large fractional bandwidth (200 MHz). In practice this would require 10 separate IF channels where each RT2832 device is tuned to the same frequency (centre of the IF band) and 10 separate VFOs to mix the front-end RF signals down into the 10 IF channels.

However, simulations revealed that there is a way of simplifying the configuration. By keeping the wide spacing of 180 MHz but reducing the number of channels back to just two gives the following result...

Here we see the peak is even sharper. It seems that the increase in DM resolution gained by increasing the number of channels at the previous narrower frequency spans (13 MHz, 18 MHz and 50 MHz) can be alternatively gained by wider frequency spans, but without needing a large number of channels.  Just why the peak is narrower is unknown to the author.  That the accuracy is increased by widening the frequency span is logical (for the reason given above), but the result, where the accuracy of the two channel configuration for the 180 MHz frequency span is the same as for the 10 channel configuration, is a pleasant one - and allows a very significant simplification in hardware.

However, the simplified 2 channel configuration comes with a caveat - examination of the DM graph shows three peaks.  The 'prepfold' module has selected the first peak (reading left-to-right) as the best value. It is unknown whether this is default behaviour (i.e., selects first DM peak) or is due to that peak having highest X2 value. In any case, examination of the graph shows that the peaks are placed at odd-multiples (N) of the correct DM value, so if 'prepfold' selects one of the other peaks then it is a simple matter to examine the DM graph to determine whether N = 1, 3, 5, etc., and make the necessary correction.

Hardware Implications for the 2-Channel RTL2832 Dongle Configuration

NOTE: the above analysis is based on the characteristics of one pulsar - Vela.  Results for other pulsars of different periods and/or different DM values will almost certainly be different also.  The hardware configurations suggested below are restricted to this limited case.

A number of different hardware configurations which could implement a 2-channel (spaced by, say, 200 MHz) RTL2932 dongle acquisition present themselves (assuming an RF front-end frequency near 1400 MHz)...

  1. A single RF channel @ 1400 MHz with a bandwidth of 200 MHz (although 3 dB points would need to be wider than this to prevent roll-off at the two frequencies). The 1400 MHz feed would need to extend down to the observatory room where it would be split and distributed to the two RTL2832 dongles tuned to, say, 1250 MHz and 1450 MHz. Requires the antenna itself to also bandwidth to receive both frequencies separated by 200 MHz.
     
  2. A variation of 1., where the 1400 MHz channel is split into two IF channels (mixed down with separate VFOs), either at the antenna proper, or at the observing position.  The dongles could then be tuned to a lower common frequency.
     
  3. A variation of 2., where the same VFO frequency is used and so the IF channels are separated by 200 MHz.  The dongles are then tuned to the different IF frequencies separated by 200 MHz (e.g., 100 MHz and 300 MHz).  Care would need to be exercised to check that any delays (if significant) through the two IF channels due to different filtering parameters are accounted for.  Some dual-polarisation configurations might be able to be adapted to this configuration.

Of course the accuracy of the time synchronisation between the two channels should be known as this will have a direct effect on the accuracy of the DM result.

As an exercise it would be instructive to repeat the above simulation exercise for different period pulsars with different DM values.  If, and when, that is done, the results will be added here.