lneuhaus
commented
6 years ago Hi,
thanks for your suggestion.
I would like to have/add the possibility to take longer traces with the scope module, i.e. reduce the sampling time. I assume you mean increase the sampling time?
The way you did that is correct, but the Python client (whose behaviour you have modified) does not find a corresponding setting in the FPGA register to go along with that sampling time.
The scope works the following way: 1) There is a buffer for 2^14=16384 points that compose a full scope trace. 2) When an acquisition is running (after a successful trigger event) at full rate (decimation factor = 1), at each FPGA clock cycle a new sample of the input signal is written to the buffer. 3) When the buffer is full, acquisition stops and you can retrieve the data to the client for displaying or saving.
With a clock rate of 125 MHz (=sampling time of 8ns), all 16k points take 8ns*16384=131072ns=0.1ms (=minimum option for trace duration).
To get longer trace durations than 0.1ms, two things can be done:
1) Wait a prefined number of cycles between inserting the next value into the scope buffer. This is done if Scope.average=False, with Scope. decimation being the number of 8ns-clock cycles per value in the buffer. Scope. decimation must be a power of 2 for implementation reasons, and is currently at most 2^16. This gives a maximum duration of 2^16*131072 ns = 8589934592 ns = 8.6 s. The sampling time here is already 0.5 ms (!).
2) If Scope.average=True, instead of taking a single sample of the input as the next scope value, the average of all input values since the last value was written to the scope buffer is taken. To get the average, the sum of input values is accumulated and eventually right-shifted by log_2(Scope.decimation), the latter being equivalent to the division by Scope.decimation. The recource-efficient right-shift is the reason why Scope.decimation must be a power of 2.
Now to your request: You must simply modify the Verilog source code of the scope to allow for longer sampling times, and recompile it in Vivado to a new fpga bitfile. See http://pyrpl.readthedocs.io/en/latest/developer_guide/fpga_compilation.html for help on setting up the process. The necessary modifications must be done - along with the Python code mods that you have already done - in the file https://github.com/lneuhaus/pyrpl/blob/master/pyrpl/fpga/rtl/red_pitaya_scope.v
Ill can submit a modified branch to show you how this must be done in case you tell me that you are unable to figure this out by yourself (its about 15min work for me, so gauge your request by how much time you loose/how much you learn from this).
Cheers
oestfeldt
I would like to have/add the possibility to take longer traces with the scope module, i.e. reduce the sampling time.
I have found the definitions of the available durations in "pyrpl/hardware_modules/scope.py" line 310. Changing this to (e.g.)
add the possibilities of selecting 17.17(...) and 34.35(...) seconds, but gives the following error messages printed to the terminal:
Acquiring single traces works in triggered mode, while the rolling mode flashes and fails to display data for longer than a fraction of a second.
I have tried digging backwards through the code to the definitions in 'attributes.py', but I have not been able to find what further changes must be done for the change to work without throwing errors (if possible at all).
// Christoffer
I hope this is the right way of suggesting improvements.
Thanks for the wonderful software.