I quickly created a new class named Detectors. I modified commit 4e1d1584181245471912d4059f630f39f65863ba from git, I added a new driver interface and enlarged the size of get/setDriverInterface type to uint32_t.
Added also two files: indidetector.cpp and indidetector.h.
All is provvisory, I successfully compiled it, but it misses many things, still incomplete, but it is a start.

Ilias.

Great progress!! Please submit a PR to INDI whenever you are ready!

Jasem, As far as you know, do you think these properties suffice?

-Bandwidth (Hz, number)
-Observed Frequency (Hz, number)
-Sample Frequency (Hz, number)
-Bits per Sample (8, 16, 32, Number)
-Capture Duration (Sec, Number)
-Capture (blob, captured data, length=CaptureDuration*SampleFrequency[*Bpp])
---
I personally would add these ones, since the receiver I'm about to buy seems to reads very slowly (Radioastrolab RAL10):
-BufferSize/Heartbeat (Number, for framed input)
-Raw wave/Intensity (Switch - maybe unnecessary as it can be done in hardware)
-Spectrum1 (Blob)
-Small library* for FFT, Graphs, imaging and statistics into:
-Render1 (Blob)
[edit]
*: this library would be useful also for photometry using CCDs on variable objects.

Let me know your opinion,
Ilias.

These look good. Bear in mind I plan also to migrate INDI SpectraCyber driver to this class, so take a look there and see if there are any other things to consider. The base class should work like others in terms of setting capabilities so that it can be customized depending on what is provided by the child class.

What small library do you have on mind?

I'd like to add a library with some functionalities and math operations used in Astronomy, like signal processing operations:
-Fourier transforms.
-Wavelets.
-Autocorrelation.
-Convolution/Deconvolution.
-Here the guiding algorithm could find place.
-Notch/Band pass filters.
-Others.
I collected most of these function into a C# library called ADPASDK (not well documented), which is part of my software, but I'd be happy to port them to INDI.

Ilias.

That would be great. Drivers that need such library can depend on it. You can create a Github project for it, and I can make an Ubuntu package for it.

Hi Jasem, I think I'm ready. I'd prefer to submit a patch here instead of a pull-request, since I don't have enough knowledge of github.
Ilias.

This is really exciting project. I have just talked to a friend, who's job is pretty much related to the topic. What he pointed out is a requirement to achieve very high time precision, reaching pico seconds. This might be hardly possible without a proper h/w rt clock. I have managed to get to nano seconds with GPS and PPS. So there's still some space for improvement. Do you guys have any idea how to address it?

PS. I think, it would be good idea to take GNU Radio into consideration

Hi Kaczorek, Thank you very much for your interest!
Instead of reaching raster high-speed fluxes one could log timestamps of pulses, or timing differences between peaks of waves. I studied a way to achieve such timing resolutions, however. Possible solutions could be Hydrogen Masers (very expensive) or Rubidium Standards. These clock types are really performant, keep in mind that Rubidium standards are the atomic clocks that the GPSs are equipped with.
The problem is how to log the pulses or waves. Since photon pulses are random one could use a TDC to keep logging the delays between pulses with a resolution of some picoseconds. There are also FPGA implementations (and open codes) of such devices so one could build with a single chip the capture and log sections.
In radio interferometry one could simply mix the two feeds using a common mixer in an analogue way and plot only the amplitude of the resulting signal, managing delays using longer or shortening cables. I know this is not a perfect solution, but it's more practical for amateurs.
Ilias.

Hi Radek,
Why do you need such resolution? Anything like VLBI ? In such case, when having the possibility to get a optical fibre link, you can reach good resolutions and stability looking at White Rabbit , which is open-source and open-hardware, but this needs very special hardware. Otherwise one can point to sub-microsecond using PTP, this could be a possible implementation but there should be many on the web: www.meinbergglobal.com/english/products/ptp-ieee-1588.htm
Ilias.

The rationale to high time resolution comes from my understanding of photon interferometry. To the best of my knowledge it must be time bound. Indeed it gets critical in long distances so I might be wrong in expecting that much... Anyway thanks for the hints.

BTW. I believe that VLBI as a social/croud sourced project is great idea. I have considered it some time ago but do not have enough time to follow up on this.

Yes! I also tried to build an optical intensity interferometer but got stuck on timing issues.
Please allow some time to add at least some receiver, initially I'd add radio receiver, mostly due to transfer bottlenecks and timing limitations. After some radio receiver photon detectors could be added.
Regarding this project, it's a common dream for interferometry passionates I think, Hanbury Brown had this dream probably, and others still too. I think that LibINDI is the right place where to start. Somebody should start a thread here where to discuss about this, and RTL-SDR receiver could be of much help here, since of their versatility and wide range. If nobody will propose a driver for these I'll do it.
There is already a project named OpenVLBA , we'd have to contact the author and propose him to bring that project INDI compliant.
Ilias