This is inconsistent with how we use UAVOs.  They always carry semantically labeled data... that's sort of the point of them.  If you create another module that produces a histogram (and honestly, I've _never_ heard anyone call a spectral estimation a histogram - that is a visualization of a distribution) you can replicate this object with another appropriate name.  

If they are both optional and run at separate times there is no cost in ram (and very little in flash).  If they _do_ both run at the same time you have avoided a bug where they both write to the same sink.

This also creates a situation where the GCS has no idea what this information means (or the log files).  It's a generic histogram.  It can only figure out the meaning by making lots of inferences by board type and what is running.

Overal making generic container type UAVOs is bad practice in our model (and I'll cop to being guilty of that with AccessoryDesired for RAM reasons and overall it's been counterproductive as we replace it with things like collective).