Yep, agree that you did. I have nothing else.
The AM32 dude has posted on here. Perhaps he should be getting more attention on the forum.
Perhaps we need a Hardware>AM32 specific thread.
And another Hardware>Speedybee (nothing to do with this post they just suck the oxygen out of the forum).
1 Like
Interesting… I did read about the ‘wraith32’ firmware on some of the AM32 docs.
I’ll try and upload this a little later so see if it does the trick at all. I did already try the Tekko 2.16, 2.17 and 2.18 but none of these worked so we’ll see.
I’ve decided against it. I get a scary looking warning when I try to flash it telling me that it may brick the ESC and I’d rather not…
Did you press the safety switch? Its enabled by default and you will get no output with it enabled.
haha yes I did. I have been flying this platform fine for a month or so now so have got into the habit of pressing the safety switch during my startup checks.
I can usually tell whether the motors will work or not before this though, when the ESCs are performing their ‘pre-safety’ beeping or whatever the proper term for it is.
When using uni-directional Dshot the beeping continues indefinitely until I press the safety switch, at which point they beep once more to acknowledge the press.
When I configure for BDshot, the beeping continues until the flight controller finishes its own initialisations, and then the ESCs go silent. Usually this means the ESCs beep about 4 or 5 times after powering up and then they stop. I press the safety switch prior to a motor test but the ESCs do not beep in acknowledgment and also I then get no control of the motors.
Okay I think I’m going to cut my losses and abandon BDshot on this platform for the time being. I was hoping to use the RPM feedback for system modelling and simulation purposes and for a slight improvement in my notch centre frequency over the throttle based notching.
I feel I’ve tried everything I can for now and I really appreciate everyones help! At the very least I think I understand Dshot and the various stages of configuration a little better now. I’m going to move on to trying to setup the FFT-based notch and I’ll think about ways to estimate rotor speeds based on the motor output commands for modelling purposes.
When I get back from the dev conference I am going to try and get to the bottom of some of these issues - I have at least one ESC showing problems.
2 Likes
SO I followed your setup as close as I could and downloaded copter 4.6.1-bdshot for Pixhawk6C, tried enablin BDshot, no luck.
However, I was thinking back to when I was writing the below quote. It got me thinking about the timing of everything and it seemed suspicious.
Doing a bit of experimenting, sharing my results below:
- downgrade to 4.6.1 and enable bdshot: same symptoms, bdshot doesnt work
- disable safety switch (BRD_SAFETY_DEFLT,1 → 0), reboot: bdshot works
- reenable safety switch (BRD_SAFETY_DEFLT,0 → 1), reboot: bdshot doesnt work
- change safety mask to allow motor control before switch (BRD_SAFETY_MASK,12543 → 16383), reboot: bdshot works
I don’t know how useful this is, but I thought it was worth sharing. The comments about the safety switch and thinking about how the ESCs stop beeping altogether after initialisation made me think something was getting confused in the safety loop. It seems that by bypassing the safety switch (either disabling it altogether or allowing the motors to be controlled before the switch is pressed), allows for everything to work as expected…
I have enough confidence in my own procedures and awareness that I’m happy to try some flights with the safety switch bypassed to see how the data looks. Obviously not an ideal fix but it may point to an idea of what’s causing this bug for someone with a closer understanding of the source code perhaps?
Rounding this off with my final setup and parameter file.
Screenshot below displays my PWM setup, my firmware version, and other details.
- I re-upgraded to copter 4.6.2-bdshot firmware
- I switched the motor control back to the ‘main’ I/O PWM outputs because the neopixels in the arms can’t be controlled by these outputs as far as I can tell, so I now have LEDs on AUX/FMU, and the Motors on I/O.
- I consequently set BRD_IO_DSHOT, 0->1
- I have set BRD_SAFETY_DEFLT, 0 to disable the safety switch as the temporary solution to this problem
- I am using BDshot600 as per the conversation above to avoid Dshot1200
Final (for now) full parameter set is linked below in case anyone is curious.
BDshotParams6.param (18.2 KB)
And below is verification that I am seeing RPM feedback for all four ESCs.
Thanks again to everyone for your time up to this stage. It’s been very helpful to have people to talk this through with and to help with the exploration of various options. Hopefully we find a more permanent problem diagnosis and solution soon!
1 Like
Ok so safety switch is the problem - there have been some fixes in this area, maybe something got broken in the process. I must admit I always run without the safety switch, so does not help with testing.
1 Like
I took the platform out flying yesterday. The logs show good RPM feedback data, and the values match up well with the detected peaks in the vibration logs too which is promising.
At one point I performed a ‘soft’ reset of the flight controller (via mission planner ‘reboot’ button) and all my flights after this point logged no ESC data, and I noticed this at the end of my testing session yesterday that the ESC feedback was not showing up in the status tab.
I’ve just recreated this on the bench too. I verified good rpm feedback, then did a ‘soft’ reboot of the flight controller, and the telemetry stopped coming through. I then did a ‘hard’ reboot by disconnecting the battery and plugging it back in again, and the telemetry was back. It looks like for some reason the flight controller stops reading the telemetry when soft rebooted via the mission planner interface… Good to know!
No just rpm at the moment.
I’ll try SERVO_DSHOT_ESC,3 as soon as I get the chance and let you know.
Yeah I am afraid that soft reboot with bdshot on iomcu does not work. The issue is that the soft reboot does not reboot the iomcu and they get out of whack, I spent some time trying to resolve this but couldn’t find the magic.
1 Like
Ah hah okay this makes sense. I’ll try to avoid soft rebooting during testing. Thanks for the info.
1 Like
I switched SERVO_DSHOT_ESC,3 and now I am getting voltage and temp data. The current never comes - the Tekko32 page says the unit is capable of current measurement so I wonder whats stopping the data coming through.
Voltages look good, temperatures are a bit confusing to me though, I don’t know why ESC1 is reading so much lower than 2, 3, 4.
Few 4-in1 ESC’s have current in the telemetry stream. Some do that have current shunt resistors on each section (4 on a 4-in-1) but it’s not common. I have one and it’s cool. But, that was when good stuff was cheap.
That Tekko unit " Onboard analog current sensor" typical of most 4-in-1’s.
1 Like
Yeah that’s the same ESC I’m running.
The screenshot above was a motor test without props so I expected the current to be very low anyway. Hoping to do some more flight testing either today or tomorrow with the EDT telemetry, will post again once I have flight data logged to see if my current values mean anything sensible.