search

tknopp / RedPitayaDAQServer

Advanced DAQ Tools for the RedPitaya (STEMlab 125-14)
https://tknopp.github.io/RedPitayaDAQServer/dev/
Other
37 stars 10 forks source link

Make a "generic" DAQ Server #3

Closed tknopp closed 6 years ago

tknopp commented 7 years ago

Our server application is tailored for specific needs. I think it would be good to have a smaller, more simple server that is more generic and allows people to try this project out. This should go hand in hand with simple Matlab/Python/Julia scripts which lets people directly plot things.

I just have not an exact vision, how a "generic" server would look like. Maybe expose the "write pointer" API similar how the SCPI interface of RP does?

jonschumacher commented 6 years ago

We could expose the functions in the library via a SCPI interface (maybe using https://github.com/j123b567/scpi-parser). The write pointer logic including its thread could be moved to the library. The thread is started in init() and the struct could be replaced by default values which can also be changed by the SCPI interface. A MEASure command can then be used to get the desired measurements.

Since all mentioned programming languages support SCPI in some way, the access on client side should be straight forward.

tknopp commented 6 years ago

That certainly is a good suggestion. On the other way its not really clear, how much we gain by this. All SCPI examples of the RP do not use a SCPI library. In the end its a command that you send over a TCP socket and the reply is pretty application specific.

jonschumacher commented 6 years ago

We could start by removing the configuration struct and replace it with default values which can be replaced via additional commands. This makes the access with various programming languages easier. Julia might serialize the struct gracefully on the client side but this is not the case with all programming languages. Could you propose default values for the struct?

tknopp commented 6 years ago

The struct is actually not really necessary on the client side. All what is done here is streaming binary data over the network socket. You can replace this by several write commands.

(One has to take care for the padding though...)

I would say: Let the daq_server how it is and lets do a new one that has minimal features (and no struct)

Default values: decimation = 16, numSamplesPerPeriod = 300, modulus = 4800

Then I would remove all the focus field handling for the moment so that numSamplesPerPeriod== numSamplesPerFrame and so on.

tknopp commented 6 years ago

@jbeuke: Hey Jonas: I had a quick look at the generic server and it really looks good! I think in the long run this can replace the MPI specific DAQ server. The only question is how to implement the transfer of fast ADC data to client computer. Is there a way to make the 8MB block of Pavels code

The only thing that we gain be my code is that the memory block is a multiple of the period length. This is a pretty important advantage, but on the other hand it would be great if CPU load and Memory load of this copying of data could be removed. So the question is if we could implement my code in FPGA.

jonschumacher commented 6 years ago

I now copied your code including the multiple of the period length thing. I don't think this makes the server less generic. On the other hand, handing the stuff over to the FPGA might be nice. Since the first stage buffer size is determined by only the wrapping of the acquisition pointer, it's quite easy to enlarge the buffer. The wrapping value could also be set via register, which allows variable buffer sizes. This would completely offload the acquisition_thread function into the FPGA. The only thing is the available buffer size: The memory address where the the RAM writer starts is 0x1E000000 which means only 32MiB are left following that address. I assume, it's not safe to simply start somewhere else, since the address range must be untouched by the OS. This limits the amount of samples which can be stored until streaming the next block. Do you think this is enough for our purpose?

I will have to think about this. For now I will try to get your approach with the second stage ringbuffer running smoothly in the new server since I need it for an experiment.

tknopp commented 6 years ago

Do you think this is enough for our purpose?

I think this is totally ok. Even the 8MB that are currently used should be fine. Its just important that our chunk size is large enough that the network overhead is minimized. but that is reached below 1MB

I will have to think about this. For now I will try to get your approach with the second stage ringbuffer running smoothly in the new server since I need it for an experiment.

+1 ping me if you need support, I can help you next week if there are things that are unclear. In our environment the server was working pretty solid.

jonschumacher commented 6 years ago

Since the SCPI server achieves the goal of being generic, I close this issue. Examples for different programming languages will be added later.