I did not calculate frequency in my code, I tried to calculate the length of the PWM then using a linear regression that related PWM to MPH display the MPH, but the PWM values I was reading don’t appear accurate

Then, show your code. As I illustrated, sometimes the obvious calculation returns incorrect results. I cannot comment on why your results are incorrect if you don’t show the calculations themselves. The length of the PWM signal is the period. Without showing how you get the value for period, no one can determine why it appears to be incorrect.

 

Then, show your code. As I illustrated, sometimes the obvious calculation returns incorrect results. I cannot comment on why your results are incorrect if you don’t show the calculations themselves. The length of the PWM signal is the period. Without showing how you get the value for period, no one can determine why it appears to be incorrect.

I did post the code with my post #16. I think you confused the code @Reloadron posted that has frequency calcs in it. Mine does not.

Here is my code again. I also attached a PDF of how I calculated the equation for PWM to Speed that is used in the falling() method

// https://www.benripley.com/diy/arduino/three-ways-to-read-a-pwm-signal-with-arduino/

volatile int pwm_value = 0;
volatile int prev_time = 0;
int total_pwm = 1023;
int max_pwm = total_pwm * .85; // PWM of the MC-2100 is a maxixum duty cycle of 85%
int min_pwm = total_pwm * .15; // Not being sent 15% of the time
float max_mph = 10.0; // our treadmill can reach a max speed of 10.0 mph
float min_mph = 0.3; // our treadmill can start as low as 0.3 mph


float cur_speed;

void setup() {
  //begin monitoring on a baud rate of 56800
  Serial.begin(56800);
  // attachInterrupt(digitalPinToInterrupt(pin), ISR, mode)
  // https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/
  // 1st param is the pin we are using, digital pin 2
  // 2nd param is the function we call once an interrupt occurs
  // 3rd param is the mode of when we should call the interrupt: LOW, CHANGE, RISING, FALLING
  attachInterrupt(digitalPinToInterrupt(2), rising, RISING);
}

void loop() { }

void rising() {
  //We know by calling this the PWM is rising, this stores in memory to call once it drops
  attachInterrupt(digitalPinToInterrupt(2), falling, FALLING);
  // In the mean time, grab the time that this function is called
  prev_time = micros();
}

void falling() {
  //Once the interrupt triggers, store in memory to keep a look out for the PWM to rise again
  attachInterrupt(digitalPinToInterrupt(2), rising, RISING);
  // do some math to calculate the PWM value by subtracting the time it takes between rising and falling
  pwm_value = micros()-prev_time;
  // this prints out the length of time the signal remains high for each cycle
  Serial.println(pwm_value);
  
  // I put the PWM values and MPH values on a scatter plot and came up with this regression:
  // s = 0.0141p - 1.972
  // where s is speed (in MPH) and p is PWM (raw units, NOT percentage)
  cur_speed = (0.0141*pwm_value) - 1.972;
  //Serial.print("MPH: ");
  //Serial.println(cur_speed);


}

 

Looking at this myself I still have not understand if there is any real problem to use the green wire, It seem that every time you get a pulse on it you just need to add the distance traveled by treadmill (that should be equal to the circumference of the front roller, where usually the sensor is).
Using this seem to much easier calculation and code logic and will give you the actual distance/speed and not the "asked" speed, e.g. the speed you see if you are in calibration mode.

Regrading the rest of the data you might want to present seem thet pressing inclide buttons give you about a 2s signal per step on Orange/Yellow wire (on my Northtrack T12si) I have not found a way to read the current value and my current assumption is to keep track of it myself in parallell in my esp32. There is a Violet that is marked "no signal" in my datasheet under the hood (by the MC2100ELS-18w) but on other datasheet on the net it seem to state that there might be some info.

If you have not found it there is a sw project for esp32 cpu's sending out this data as standardize BT data here https://github.com/jamesjmtaylor/esp32-ftms-server
Using this various existing apps can get the data (like Zwift) or your own.

On my treadmill I had a bit of luck and the easy access buttons on the front bar e.g. start, stop, speed +/- and incline +/- are in put into one connector with the 8 cables from/to the MC2100ELS going to the console/computer/brainboard. I got one wire per each button so with a bit of luck I can quite easy fake button presses this way to control it (at least incline I'm not sure I'd like to control speed yet). I hope your treadmill also have something like this.

I tried to find something on the console/computer/brainboard to read/write the button info but for me it seems like the easiest way is to just peek/poke the cable and it should be good enough. The best I found on the motherbord was unknown serial protocol between the console/computer/brainboard and the front display&button board (seem to be called membrain).

 

Sorry linked wrong project it should have been this for BT treadmills
https://github.com/lefty01/ESP32_TTGO_FTMS/

 

Some more findings: I used a cheep €13 logical analazer to check the signals and it seem to happen some magic on the Violet "no signal" line (pin7?) to or from the MC2100els in my case during the incline/decline. No idea if it could be used to check for a endpoint or keep better track that dividing the up/down signals with 2 seconds.

I also checked the green tach cable (pin 3?) and running it on 2km/h got roughly 182 beats per min, accroding to my calibration menu my front roler (rOL) is 1.9 if I assume that is in decimeter I get the speed 182×60×0.19÷1000 = 2,0748 km/h.