Dynamic PPM source enhancement

[unxs0]

Provide a way to for AIS-catcher to get a new -p value from some IPC method.

Why? Since inexpensive RTL dongles (that developing nation users can better afford e.g. RTL2838) have a very wide crystal drift depending a lot on temperature among other factors. And since a new PPM value can easily be calculated by different means including using cell tower and even approximated by environment temperature. It would be useful to be able to set the -p value that a running AIS-catcher instance is using. As long as it can be updated every 5 minutes without impacting performance it would be a great help.

Thank you for your consideration.
Cheers!

[jvde-github]

Thank you. I like the concept of catering for these dongles.. I don't understand the process though of how to estimate the drift without stopping the receiver to recalibrate. I recently added the AFC_WIDE option that makes the decoder more robust for drift (at the expense of sensitivity). That was a quick fix at the request of a user. Since then I was thinking about some additional ideas to compensate for drift within the receiver itself. For example, the webinterface now shows the development of the drift over time. Perhaps we can use this to auto correct the decoder. It seems to give an accurate estimate for the frequency offset but requires quite a few messages to establish a decent estimate. Still this could work if drift is slow enough.

I am also happy to take external input if that works better but need to think a little bit of how this could work.

Thanks!

[Taxom]

I do not think that this is necessary, the oscillator frequency drift is very small. Although it may be strongly shifted from the declared frequency. I have a cheap dongle on my ASDS-B feeder, which is more than 10 years old, the frequency shift on it is more than 50 ppm, but the temperature drift is not more than 1 ppm with a difference of temperatures from +5 to +60°C.

[jvde-github]

There seems to be sometimes some dongles with serious drift: jvde-github/AIS-catcher-for-Android#6

Having said that, I do think that the automatic frequency correction that is currently implemented could benefit from a review and some more experimentation. Currently it is a fairly straightforward FFT correction method and have not experimented with other methods. This could make the program more robust for PPM deviations in the receiver and sender.

[Taxom]

"There seems to be sometimes some dongles with serious drift: jvde-github/AIS-catcher-for-Android#6"

I think this is just a defective quartz oscillator. Although if the addition of automatic frequency correction is not a problem, then it will not be superfluous.

Thank you so much for your work!

[unxs0]

Agree with all above. I can provide some supporting evidence of correlation between drift and case temp of dongle:

I collected 400 data points, case air temp vs ppm, of actual AIS messages using a common hi drift dongle. Data is from a fixed base station with high shipping traffic and loaded it into a spreadsheet and ran a correlation function getting 0.65 (1 would be perfect correlation).

Spreadsheet Summary

As shown in the image linked above I calculated a simple linear regression to create a slope intercept equation that I am using with success to reload AIS-catcher with a new error ppm every 5 mins if the calculation returns a different error ppm than the current one.

I am sure that the coding guru's here can create a much better automatic ppm correction scheme for high traffic areas. But from what I understand this would not be very useful to a lone fishing boat boat in Malasia with few messages. In that case the optional auto ppm correction switch could generate a formula for correction (correction setting probably non linear) based on an initial "calibration" run done in their busy home port.

Cheers and great work! I am comparing to comercial COMAR unit and getting excellent results.

[jvde-github]

Interesting, thanks for sharing. I am going to look more in detail at the frequency correction. Not sure where it will lead but will take this observation into account (i.e. how to include information beyond what we get back from the AIS signals).

[jvde-github]

I have introduced a model that hopefully is a bit more robust to frequency offsets and does some partial correction automatically. Although still in a small range, see.

One approach I see is to run the program, say with -T 3600 for an hour and then either calculate a new p value, for example using your interpolation or (what I do) pick a base station that seems steady and use the average ppm correction that was necessary for this base station as an estimate (assuming the frequency drift was only caused by the dongle).

Unfortunately, it is not possible to reset the ppm whilst the program is running for now. There is a mechanism now for updating the station location (sending UDP lines), perhaps we could extend that to accept also new settings.....