Is there a way to provide user parameters for measurement extensions other than hacking values in the extension code?
HLAs provide a settings edit dialog with provision for adding custom settings parameters. I don’t see a way of doing that for measurement extensions.
My immediate use is a burst analyzer digital extension that generates timing statistics for bursts of activity (think async serial or SPI transfer bursts). I’d like to be able to easily set the minimum ‘idle time’ parameter used to determine what constitutes a burst. At present that value is baked into the Python source meaning a reload of the extension is required whenever I want to change the parameter.
@P.Jaquiery Besides manually hard-coding certain settings, we unfortunately don’t have a native way of providing user settings for measurements.
Can you share more details about the kinds of timing statistics you are gathering for the bursts of data?
Sure: I’m interested in the timing of bursts of activity so I’ve adapted my Pulse Stats measurement extension to generate min, max, average and standard deviation stats by treating the starts of bursts of activity as the starts of burst periods.
I use the information to check that ADC unloading has low jitter and is at the right rate and other similar problems where I’m interested in timing of bursts of activity.
I’ll probably add the extension to the market place in due course, but the idle time parameter is critical to any particular measurement and hacking the extension source to edit it is a bit clunky, and maybe beyond what some users could be bothered with.
@P.Jaquiery Ah I think it makes sense now. Thanks. You essentially want to ignore the idle periods in your final measurement, and only care about pulse stats from within the bursts themselves. Hopefully I understood that properly.
Having a dedicated idle time parameter does seem to make sense. I’d suspect lots of users could make use of this for all kinds of measurement extensions. I’ll bring this up with the team here.
The other way around actually - although I can see uses for your interpretation. If you zoom out to the point where you can see the bursts of activity as a solid block, I’m interested in measuring from the start of each block (the burst) to the start of the next block so I can get information about the overall block frequency and timing.
In the ADC unloading case there is a burst of activity every time a sample set is unloaded, then an idle time until the next sample set is unloaded. I’m interested in the time from one sample set to the next. The ADC I’m working with is effectively 8 ADCs in parallel so it collects 8 samples at the same time then shifts them out using SPI.
In another case I have some high speed async serial debugging generated every time an event of interest happens and I want to time the events. I could waggle an output pin at the start of the event and measure that, but the debugging is already there and I don’t have a convenient spare pin to waggle.
1 Like
FYI - I’ve published “Burst Stats” in the Market Place.
1 Like
Thanks for sharing your extension! Ah your use of the measurement extension makes sense now. Thanks for describing that.
@P.Jaquiery I wanted to follow up with you on this topic. We couldn’t get this prioritized, though we do have a list of improvement ideas that we’d eventually like to implement for extensions. We would likely implement a majority of these in bulk when we get to working on extension improvements.
For now, I posted your idea below, with a link to this forum post: