We had to cancel our weekly Monday meeting due to illnesses but we have at least made some small progress we can write about.
The radio dongle code has been updated to flash either of the two LED’s when sending data or in case of bad transmission.
On our latest prototypes we discovered that the radio transmission went pretty bad on some copters as soon as the motors where turned on. This was not a nice discovery at this time of our project and we had not really seen it before. This kind of problem could require a big re-design of the PCB! After some debugging it turned out to be the PWM switching of the motors causing ripple on the digital supply voltage. It wasn’t that much, about 60mV peak-to-peak but enough to throw the radio off balance. After some tries with different decoupling techniques to get rid of the ripple, which showed only minor improvement, we increased the motor PWM frequency from 17kHz to 280kHz. That made the ripple go away, now about 10mV peak-to-peak, and so did the radio transmission problems, yeay!
12 comments on “A little bit further”
Great progress! Keep up the good work!
Will the increase in frequency decrease the battery life?
The increase in freqency should not show any notisable difference in battery life. The switching losses in the transistors will increase but the coreless motors are actually a bit more efficient at a higher frequency. We will have to do a test to find out, which we will do eventually.
So whats the forecast on when these are going to be available?
Our goal is to make it available during the first half of 2012.
oh, does it currently work also with Xbox 360 controller?
At some point in time we had it working with both the Xbox 360 and the PS3 controller but dropped support for the Xbox 360 since it was messy with our old implementation (and we all had PS3 controllers). Now that we have restructured the PC application a bit we are planning to (in some form) put in support for other devices. We use pyGame for reading the input device so basically what’s needed is to remap the axis for the controller.
How about a rough number?
If it is possible to go to 280kHz why did you choose 17kHz before? Isn’t a higher PWM freqency always creating a cleaner sine for the motor, or where you afraid of other EMC affects?
The trick is that, to avoid noise on the analog sensor measurement, we where synchronising the analog sensors acquisition with the PWM (the STM32 permits to synchronise timer together and the ADC acquisition was launched some time after the PWM edge). So the PWM had to be slow enough for the ADC to do the acquisition when the power supply was stable.
So part of the discovery is also that this advanced acquisition scheme is not required anymore.
hey all, i am interested in knowing the specifications of the motor you have used.
They are brushed coreless 6x15mm motors.