I have a signal sampled a 100KHz, i feed it 0.1Sec slices to a spectrogram block, this gives me 10.000 samples.
The spectrogram has following settings :
Frame length 0.05 Sec, thus 5000 samples per block
Frame stride 0.0025, thus 250 samples increment per stride
From this i would expect the dimensions of data to be fed to the spectrogram to be (signal_length - (frame_length - stride)) / stride (10_000 - (5000-250)) / 250 = 21
21 blocks of data, each 5000 samples long.
With 256 Frequency bands i would expect (256/2)+1 = 129 bins output, and one output for each of the 21 blocks, thus 21*129 = 2709 spectrogram “pixels” as per Spectrogram docs
However my model_metadata.h shows #define EI_CLASSIFIER_NN_INPUT_FRAME_SIZE 2580
Which corresponds to 129*20, so to me it seems like one data block is missing in the calculation of the input to the NN.
The results in an EIDSP_MATRIX_SIZE_MISMATCH error when doing inference in extract_spectrogram_features-> calculate_mfe_buffer_size -> calculate_no_of_stack_frames
since calculate_no_of_stack_frames returns 21
Is there a possible ceil or floor bug when calculating the expected input to the NN, during deploy ?
or where may i have gone wrong ?
Your formula looks correct. Is it possible that some of your samples are not aligned on 0.1sec windows? (ie samples of length: 1.21sec). In the Impulse Design you can enable zero-pad data and see if it fixes the issue. Also feel free to share your project ID and we can have a quick look at the different parameters.
Thanks Aurelien, i’we tried zeropadding in the impulse design, outcome was the same, project ID is
63983, thanks if you’d take a look in processing.hpp multiple places i see if(zero_padding) used to determine if the number of frames shall be ceil() of floor(), which actually makes the difference between 21 and 20 in the number of blocks, in my case. But i can only see these functions e.g. stack_frames(...) called with zero_padding=false
For my project it is is ret = processing::stack_frames( &stack_frame_info, sampling_frequency, frame_length, frame_stride, false, version);
I’ve looked at your project and you are correct the number of features should be 2709.
Actually if you copy an example of generated features from the Spectrogram block, you will have this correct length. However we seem to pass an array of 2580 to the NN block in the Studio (might be a wrong reshape). I forwarded to our core engineering, we’ll keep you posted on the investigation.
My guess… We’ve had a bug in this block in implementationVersion 1/2 where this occurs, but I see that your block is on v3 when looking at DSP screen (where feature count is OK). I wonder if something in the EON Tuner uses the wrong implementationVersion of the block during training, yielding the wrong count in the Keras block. Have pinged our embedded folks to look at this.
@morten_ece_au We indeed found a bug in our frame stride / length calculations in our DSP blocks. This has now been fixed and merged in, will be released in the next patch release (probably tomorrow). Thanks again for the report!
@morten_ece_au We’re working on a changelog feature in the Studio for this type of thing. Public repos can be used in theory, but we export about once a month, so not always up to date.
tried spawning a few new project to make sure it would include updates, both spectrogram / MFE, same shapes as above, but patch is not pushed yet, right… ? (if it is, the issue persists )
in 
)