Does BT Telemetry Impair Control Circuit Response?

[gonnabiff]

I'm sure someone with knowledge of the required frequency response of the control circuit to keep wheel balanced within design performance parameters can answer this.

But I did speculate, I want my wheel to pay full attention to staying under me. If say interrupts keep arriving to CPU to report voltage and wheel speed and temperature and so on to a BT transmitter to display on my phone app, does that bog it down and impair wheel control?

Perhaps there is no processor, simply an analog motor control with dedicated logic for user-adjustable tilt response/ride quality and max speed, decreasing battery voltage, current exceedances, etc., and then various sensors polled by an independent Bluetooth module. In which case nothing is monkeying with motor control.

Someone please straighten out my thinking. Thanks.

[Hunka Hunka Burning Love]

Those values are constantly monitored by the MPU and likely recorded in registers so a program like Wheelog or Gyrometrics likely just samples the same registers through the BT module without creating much extra processing overhead I would guess.  Maybe @esaj or @electric_vehicle_lover or @Paco Gorina might be able to comment on that further.  These wheels mostly use the STM32F103 processor which likely is able to handle everything just fine.  It would be interesting to see a processor demand graph to find out how much it is actually being taxed.

[electric_vehicle_lover]

7 hours ago, gonnabiff said:

But I did speculate, I want my wheel to pay full attention to staying under me. If say interrupts keep arriving to CPU to report voltage and wheel speed and temperature and so on to a BT transmitter to display on my phone app, does that bog it down and impair wheel control?

On the firmware I did and I am developing, for Unicycles or EBikes https://opensourceebikefirmware.bitbucket.io/
the UART/Bluetooth communications interrupt have lower priority than the motor control interrupts. The motor control interrupts like the PWM interrupt have the top priority so the motor control code will always run! Here is my current firmware for the motor controller and communications controller:

while (1)

{

// because of continue; at the end of each if code block that will stop the while (1) loop there,

// the first if block code will have the higher priority over the others

ui16_TIM2_counter = TIM2_GetCounter ();

if ((ui16_TIM2_counter - ui16_motor_controller_counter) > 100) // every 100ms

{

ui16_motor_controller_counter = ui16_TIM2_counter;

motor_controller_high_level ();

continue;

}

ui16_TIM2_counter = TIM2_GetCounter ();

if ((ui16_TIM2_counter - ui16_communications_controller_counter) > 150) // every 100ms

{

ui16_communications_controller_counter = ui16_TIM2_counter;

communications_controller ();

continue;

}

ui16_TIM2_counter = TIM2_GetCounter ();

if ((ui16_TIM2_counter - ui16_throttle_pas_torque_sensor_controller_counter) > 100) // every 100ms

{

ui16_throttle_pas_torque_sensor_controller_counter = ui16_TIM2_counter;

throttle_pas_torque_sensor_controller ();

continue;

}

}

https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/blob/master/motor_controller_low_level.c

https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/blob/master/communications_controller.c

[Paco Gorina]

On 27/10/2017 at 6:45 AM, Hunka Hunka Burning Love said:

Those values are constantly monitored by the MPU and likely recorded in registers so a program like Wheelog or Gyrometrics likely just samples the same registers through the BT module without creating much extra processing overhead I would guess.  Maybe @esaj or @electric_vehicle_lover or @Paco Gorina might be able to comment on that further.  These wheels mostly use the STM32F103 processor which likely is able to handle everything just fine.  It would be interesting to see a processor demand graph to find out how much it is actually being taxed.

I believe there is no problem or at least I have not seen it in Ninebot  or the Rockwheel GT16.