Float Array rolling over

I will paste the full code this evening, but this may be a question that could be answered without it because it looks like I have a fundamental misunderstanding..

I have a sketch that is a basic datalogger. It only reads data from one hall sensor every 100 milliseconds and stores it in an array. That array is initialized in Setup thus:
Float Array[500];
The Loop then starts writing data to it with a For loop incrementing the index.
However, the index only reaches the magic number of 255 before rolling over to the index 1.

I think, even as I write this, that the problem is somewhere in my For loop, not the Array[500]...

Your loop index is probably a char type

No it is not. Post your code, it could be just an index defined as "byte" (unsigned byte, i.e. from 0 to 255).

Are you sure? The rollover for a byte variable incremented by 1 goes to 0 not 1...

Its not, but you pointed me in the right direction and the answer is so obvious! its a byte!

The capital F is strange but it might just be an autocorrect issue when you typed .

That’s not an initialization, it’s the definition of the array (memory allocation for 500 floats or 2000 bytes. If you are in a UNO R3, that’s probably too much!)

Also if it’s really in setup() then its scope is limited to that function - the array is destroyed once the setup() function terminates and enters the loop().

Absolutely right. The very first question that came out to me while reading the post is: why a Hall sensor would require a float data type?

If it's like the ones I've seen so far, it has a digital and an analog output: I imagine the digital one isn't used, but the analog one uses analogRead(), which returns a value between 0 and 1023 as the "raw" value, and requires only 2 bytes as an integer, so the array will be half the size of the float.

I assume the float they currently stores is the result of some calculation based on the value read with analogRead(), but to save memory, it would be enough to store the "raw" value and perform the calculation when "extracting" a value from the array.

Lastly, if the range 0-1023 wasn't necessary and 256 levels were enough, you could even use map() to return the value between 0 and 255 and store that in the array, which would be a quarter the size of the float...

a value between 0 and 1023 as the "raw" value

@docdoc
One could pack four 10 bit values in 5 bytes, (OK it is a serious lesson in bit math).
So in the approx. 1800 free bytes (UNO R3) one could store ~1400 measurements (lossless).

FYI, I recently started coding a library to use “Time Length Compression”, a variation on run length compression, with a duration instead of a count. For slow changing series only.

I've moved from an Uno to a Teensy 4.0 simply because the limitations of the Uno's memory for float arrays (plus I have some from a previous project)
The hall is used to measure pulses and then the time between pulses is used to calculate speed which is then exported via a CSV file for an Excel program. The speed is using a float as its in M/s.. 0.00

Have you ever considered doing the calculation at export time instead of storing the computed value and then exporting?

Yes, the excel program its going to is pre existing and expects a CSV file.

BTW, thanks for everyones help with this. I'll try to post the code this evening then you can all really savage me :slight_smile:

You either missed my point or just ignoring it.

Missed it :slight_smile:

The point was to store the raw values in a much smaller table. When time to create the CSV data, do the calculation then.

Given he is on a teensy, memory is less of an issue.