I am working on writing some custom FPGA code to work with MCC, and it looks like the documentation only has a “data” input/output. I’m wanting to have a type of output gating function (e.g. decimating the signal), which would need a “valid” signal to tell the downstream component to only transfer data at for certain samples. Can it handle something with data and valid instead of just data?
We do not natively have this feature inside MCC right now, although it is a great idea! What is it that you have next in your MiM chain after this MCC block? (for example is there another instrument you are sending this data to like the oscilloscope or is it to the DACs?)
If this is being sent to an instrument like a scope or data logger, then it should not need decimation. But if you are sending this to the DACs then you may have to implement some interpolation to get an appropriate output sampling rate. MCC should still be able to handle this either way, but I am curious what your application is and what else you are planning to use MCC for!
The application that I’m thinking of is basically a threshold trigger, where I apply a matched filter to the data with some preloaded coefficients. Whenever the matched filtered data is above some specified threshold, then I’d output a section of the data that is centered on the part of the data that is the farthest above the threshold value. My thought was that this would work well with the Datalogger, where I could use it to save the outputted sections of data.
My understanding was that the FPGA might have some latency if it needs to do the calculations in time, so it would be better to decimate the signal to ensure that the latency is minimal, and this is where the valid out would come into play.
I haven’t yet had a chance to upload the FPGA code to the Moku, but hopefully will soon!
Even if MCC had valid out, the data logger does not have valid ins, while running it always collects data at full rate and has its own internal decimation. Saving “snippets” of data, decimated or not, falls under the category of “triggered data logging” and isn’t supported with or without MCC in the loop. It will be at some stage, this is certainly a very powerful potential use case for MCC in the future!
Your best bet at this time is to still implement the MCC code as you describe but just have the data logger running and then parse the data afterwards. It isn’t possible to ask MCC to interact with another instrument at this time, but as I said this is an awesome potential!