GoForSmoke:
Gear tooth counters do NOT touch the gear teeth. The movement of the metal tooth in the counter's magnetic field changes the field as the field induces charge in the tooth and a Hall Sensor detects that. A cheap commercial GTC may run about $20 or less.
a hall sensor costs a dime and my custom PCB´s are already designed with hall sensors in mind.
Also, i am planning on using my old bike computer sensors in case im not happy with the hall triggers ive already purchased.
I was initially concidering using the brake disks as ABS encoder rings, reading the gauss fields leaking thru the cooling holes of the brake disks, but i eventually ditched that idea since it would require me to have a very specific brake disk design, i couldnt mount other brands since the holes would not be in the same locations.
GoForSmoke:
The more you have being calculated the more cycles you want to save. Table what you got room for, when you compile you know how much you used.
Are you going to switch timing to micros()?
That is true indeed.
However, this table solution requires a single, hard-encoded wheel size, witch wouldnt be accurate if i change tires to another dimension (width).
I do have more than one bike and i aim to use this project on them all, so a easily configurable wheel size seems like the better option.
As far as i understand things, 33 rotations per second on the measured wheel (standard 28") will measure 251km/h, giving a average read time of 30,30303 ms per rotation, or 90,9 ms for a set of rotations (calculating average over 3 rotations).
At 10 rotations per second (76km/h), the average read time would be 100ms or 300ms for that set of rotations.
uint32_t speedTemp = ((36 * distance) / elapsedTime);
The code would then be read as (36 * ((2114*3)*100)) / 300, or 22831200 / 300 = 76104.
if we were to add two milliseconds, just to calculate the error difference, our numbers would look like this:
22831200/302 = 75600
22831200/298 = 76614,7651006711
So: 76104 - 75600 = 504
and 76104 - 76614 = -510.
since we´re dividing by 1000 to get the km/h, adding those error differences gives us a maximum error of 1.1km/h, given a millis accuracy of +/-2ms
I grant you that there is room for improvements there, but at the same time, a 1km/h accuracy is not a dealbreaker for me.
GoForSmoke:
How many magnets are you using? --- feeds into time between reads and practical ways to improve accuracy.
Im currently not using any magnets, but the plan is to use 1. I might eventually increase that number to 4 but thats ways down the road, nothing that´ll happen in the near future..
GoForSmoke:
I tightened my spokes with a spoke wrench and kept my wheels true. A trued wheel is stronger. Why in H would I do something so stupid as gluing spokes together? It won't make the wheel stronger unless that wheel is a mess to begin with. Ask a competent mechanical engineer some time.
When I last rode like that, it was in the 80's before I turned 30 (also in the 80's).
A shorter spoke is stronger because of physics. 
And by tying them together, you are effectively using spokes half their actual length.
You would of course have to have the wheel true and strong before you tie the spokes, but according to those who tried, the result is quite dramatic.
As i said earlier, i have never tried it, but if i were to load my wheels with greater forces than they are designed for (more weight and/or higher speed), i would try it.
But i would also spend some time balancing the wheel afterwards, if the goal was high top speed.
Wvmarle: I do understand that a simulator is not a exact representation of reality and IF i were to need exact numbers, i would have used real hardware.
But a simulator is supposed to proximate reality, a result in the sim gives a hint that you would get similar results on real hardware.
If this were not the case, why would anyone use a sim in the first place?
..Quite frankly, it feels like youre just moodily arguing, perhaps because you cant handle being corrected?
I dont have this project running on a actual hardware yet, simply because im not there yet. In other words, i dont have a function generator to simulate wheel rotations in real life, nor do i have the patience to build a circuit merely to measure something that i really dont NEED to know exactly at the moment; i only need a hint.
Once im ready and running on my project hardware, i will be doing the same comparison as i did in the simulator, as well as checking alot of other metrics from the system, but at this very moment, the simulator says floats are 3 times faster.
If you really want to prove me wrong, rig up your own experiment and present some numbers, a mere bickering attitude isnt really constructive...