Discussions about active development projects
#7368 by Nils Roos
Sun Mar 19, 2017 11:04 pm
Amraam wrote:I'm considering the possibility to implement mods to manage triggers, could you tell me all the infos that you consider relevant?
All details are appreciated.

Hi Amraam,

My idea for this was to have a counter running from 0 with the effective sample rate and just store the counter value when a trigger condition is recognized. On the software side, you could poll the corresponding register and take appropriate actions when it changes. The new value would allow to identify the position in the sample stream where the trigger happened. Another idea would be to tie the transfer to ram to the trigger signal, start the transfer upon trigger and leave it running for a configurable time. You'll still need to implement a counter for when the trigger happened exactly, because the transfer logic stores blocks of 512 samples and you only know that the trigger position is somewhere in that frame without a counter.
#7373 by achimoe
Mon Mar 20, 2017 2:58 pm
Hi Nils,
thanks a lot for the quick answer, it worked as described.
According to my quick tests loading this binary has no effect to subsequent usage of the oszilloscope app.
Are the standard apps always reloading the standard binary?
Or is the modified binary compatible with the oszilloscope app?
Sorry if these are FAQs but so far I didn't find too much answers to such questions, any pointers are welcome.
Thanks,
Achim
#7386 by Nils Roos
Thu Mar 23, 2017 8:26 pm
When you start a web-app, the bazaar infrastructure will load the bitstream that the app needs (configured in the app's fpga.conf).

The modified binary is mostly compatible with the standard apps, with the one exception that the decimation settings do not match. The standard bitstream allows settings of 1, 8, 64, 1024, 8192, 65536, whereas the ddrdump.bit supports 1, 2, 4, 8, 16, ... 65536 .
#7439 by kumeet
Sat Apr 08, 2017 5:19 am
Hi Nils.

Thanks for your work on rp_remote_acquire. I have managed to get this working, however I would like to try to add some simple data processing to acquired values, before they are sent to data socket. I have some prior programming experience on c from years ago, but willing to give this a shot. Can you point me to right direction how to get started on this?
#7445 by Nils Roos
Tue Apr 11, 2017 7:51 pm
Hi Kumeet,

the functions transfer_buf_* in transfer.c copy samples from the DMA region into a local buffer before moving them to the network or storage. These local buffers would be the place to do some more processing.
#7458 by kumeet
Fri Apr 14, 2017 5:55 pm
Nils Roos wrote:Hi Kumeet,

the functions transfer_buf_* in transfer.c copy samples from the DMA region into a local buffer before moving them to the network or storage. These local buffers would be the place to do some more processing.


I managed to recompile your work and got it running and working on RP.

I have been trying to understand your code for the change I need to make, can you correct if I am totally lost:
So I see the data is transfered to the datasocket in chunks sized 16384 int16. What I would like to do is to take this data, scale all points with 16 (2^4), reshape it to 2D array (16 x 1024) and then sum array elements by row to get 1x1024 array of int16. Then instead of 16384 int16 values, only 1024 int16 values are sent to datasocket. So effectively the data sent to socket represents an average of 16 "waveforms" with a length of 1024 values.

I have not yet looked how to realize this in C, but do you see any problems in my idea? Should I be able to do this just by modifying the transfer_buf function?

Thanks in advance

Who is online

Users browsing this forum: microwavejoe and 1 guest