Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
development:realtime [2018/03/12 09:36]
robert removed outdated list of publications using FieldTrip buffer
development:realtime [2018/03/28 14:09]
robert [General tips and tricks]
Line 28: Line 28:
   * Are you having performance problems? Maybe you can initially try to reduce the number of channels or the sample rate, and check whether the program logic is right.   * Are you having performance problems? Maybe you can initially try to reduce the number of channels or the sample rate, and check whether the program logic is right.
   * How much data are you trying to move? If for example you want to write to a buffer on a remote machine, you need to be aware of the physical limits of the network connection.   * How much data are you trying to move? If for example you want to write to a buffer on a remote machine, you need to be aware of the physical limits of the network connection.
-  * You can try moving the actual buffer to another machine, and you do not need to have the buffer attached to a Matlab session (try using ''​demo_buffer''​).+  * You can try moving the actual buffer to another machine, and you do not need to have the buffer attached to a Matlab session (try using the ''​buffer'' ​application that you will find in fieldtrip/​realtime/​bin).
   * You can try to report and compare the wall clock time with the sample time. Here, wall clock time refers to the real time your computer has run since you started the acquisition loop, while sample time is given by the amount of data processed so far, divided by your sampling frequency. These two numbers should ideally be the same or have a small constant offset, but they should not drift apart. Successive sample and clock times should also match your blocksize, that is, if you always read 500 samples at a time from a device, and your sampling rate is 1000 Hz, your measured clock time and calculated sample time should increase roughly by 0.5 seconds after each block.   * You can try to report and compare the wall clock time with the sample time. Here, wall clock time refers to the real time your computer has run since you started the acquisition loop, while sample time is given by the amount of data processed so far, divided by your sampling frequency. These two numbers should ideally be the same or have a small constant offset, but they should not drift apart. Successive sample and clock times should also match your blocksize, that is, if you always read 500 samples at a time from a device, and your sampling rate is 1000 Hz, your measured clock time and calculated sample time should increase roughly by 0.5 seconds after each block.