I think the overall goal for now is to create a base class that can be subclassed by concrete implementations later on. Perhaps it is best to create base and then implement your detector as a child class. Like Telescope and CCD classes, you can switch capabilities by setCapabilities(..) function. Maybe I'll also migrate Spectracyber to this base class later.

I'll do happily this work, please allow some day because I'm full of work in this moment.
I'll add the minimum required in a base class for monodimensional detectors (like Detectors class), then some sub-class could be "Analog Detectors" and "Pulse Detectors" (general, because one could use PMTs or APDs, or else Radio receivers).
Ilias.

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.