3DR Solo ESCs Firmware: Updates?

[Saijin_Naib]

We have SimonK firmware of some revision or another from what I've gleaned here and the 3DR GitHub.

It looks like 3DR's snapshot of the SimonK firmware GitHub repo is dated has not seen a commit since 2015, whereas the upstream SimonK GitHub repo has seen a commit as recently as this January, with many of the files having revision dates three years more recent than the snapshot in the 3DR/Open-Solo GitHub.

My question is this:
Can we flash the ESC firmware? Has anyone done it to get updates on the ESCs?

Has anyone tried cross-flashing them to blheli? I've seen lots of evidence from miniquadtestbench that supports that blheli/oneshot can make big gains in thrust and power efficiency, even between recent revisions of the firmware. blheli is also under absurdly heavy development, having seen a commit as recent as an hour ago at the time of writing.

We're pretty out of date to say the least...

Or am I completely off base here?

 

[Pedals2Paddles]

You probably could if you wanted to be a test pilot and build an interface hook up a programmer. However, I don't think you're going to gain anything by doing so. The Solo's raw power is limited by the slew rate limiting code on the pixhawk. This limits the control output's rate of change, which reduces the throttle's overall rate of change. 3DR put that code in there as a hack to mostly mitigate a hardware problem the ESCs have. There is a ground bounce condition at high power surges that causes the ESCs to reset in flight and usually crash. So the solo's throttle is intentionally handicapped by this. Updating the ESC firmware won't fix the ground bounce, and will be totally moot by the slew limiter.

If you put in the Green Cube, which properly mitigates the ground bounce by using 5v signalling, and run ArduCopter 3.5 without the slew rate limiter, the Solo is totally different animal. The power difference is dramatic. No ESC changes needed.

 

[Saijin_Naib]

I'm not so much interested in raw power as I am possible efficiency gains and maybe that elusive metric of "responsiveness", though the Solo in manual at 100% rates can outfly me easily.

I thought that ESCs with a semi-recent bootloader can be flashed via the Signal wire, right? Is there no way to kick this process off with everything onboard intact through the IMX without pulling everything apart and making a custom flashing harness?

I have no problem guinea pigging this, I just don't know how to get to that point yet as I first have to see if we can even flash the ESCs.

 

[Pedals2Paddles]

The motor pods connect to the pixhawk through the carrier board. No connection to the IMX. There is ground, 5v for the LEDs, i2c for the LEDs from the pixhawk, and PWM for the motors from the Pixhawk. So I think you would need to unplug them and use a custom harness.

 

[Saijin_Naib]

The motor pods connect to the pixhawk through the carrier board. No connection to the IMX. There is ground, 5v for the LEDs, i2c for the LEDs from the pixhawk, and PWM for the motors from the Pixhawk. So I think you would need to unplug them and use a custom harness.

With the soldering skillset of a potato, this should go well. I'll report back haha.

 

[hackbard23]

You probably could if you wanted to be a test pilot and build an interface hook up a programmer. However, I don't think you're going to gain anything by doing so. The Solo's raw power is limited by the slew rate limiting code on the pixhawk. This limits the control output's rate of change, which reduces the throttle's overall rate of change. 3DR put that code in there as a hack to mostly mitigate a hardware problem the ESCs have. There is a ground bounce condition at high power surges that causes the ESCs to reset in flight and usually crash. So the solo's throttle is intentionally handicapped by this. Updating the ESC firmware won't fix the ground bounce, and will be totally moot by the slew limiter.

If you put in the Green Cube, which properly mitigates the ground bounce by using 5v signalling, and run ArduCopter 3.5 without the slew rate limiter, the Solo is totally different animal. The power difference is dramatic. No ESC changes needed.

thx for your explanation, as i understand there is a difference in the update rates from PH output and the ESC input. Seems that 3DR used software to buffer or "peek and hold" the duty cycle.
But i can´t see why a higher PWM amplitude could fix that ?
normally ESC´s input update rate should be elevated to get rid of the flaw and make the bird more responsive

 

[Pedals2Paddles]

It's not a PWM rate problem. It's a flaw in the hardware design. Under heavy rapid surge load, the ground lift causes the signal voltage it sees to drop. Once it drops below 2.3 volts, the ESC shuts down. The slew rate limiting code in the custom ArduCopter version is nothing more than preventing the copter from being able to rapidly surge power through the ESC. While it mostly mitigates the problem, it also handicaps the throttle. And it isn't a 100% fix either. The green cube uses 5 volt signalling, which prevents the ground lift from dropping the voltage anywhere near 2.3 volts. Which means you no longer need the slew rate hack.

 

[hackbard23]

hmm, if there is a ground lift under heavy load there must be a resistance between battery GND and the motor - i doubt it´s to thin cable, motor just sucks max. 5 Amps
the only thing between the motor and GND normally is the MOSFET himself - if it´s RDS On value has to much resistance, that could explain this behaviour

 

[just_bruce]

It's not a ground lift, it's a ground bounce. And it takes place within the PixHawk , on the signal line output.

 

[Pedals2Paddles]

I think ground bounce is the right term, but it's been called both. It's not in the pixhawk though.. It's in a transistor in the ESC. I don't know which one..

 

[hackbard23]

let´s see:

voltage sink is ~1V at ~5A that would be 200mΩ RDS On
LOL, 5W heater....
this must be the worst MOSFET Transistor i´ve ever seen....

think i have to examine the motorpod to see what the f**k they managed to screw up

 

[Pedals2Paddles]

this must be the worst MOSFET Transistor i´ve ever seen....

Quite likely. Lol.

 

[just_bruce]

I think ground bounce is the right term, but it's been called both. It's not in the pixhawk though.. It's in a transistor in the ESC. I don't know which one..

That makes zero sense. Ground bounce at the sink end shouldn't change the perceived signal level, since it is essentially floating there anyway.

And everything I've read referenced the Pixhawk when discussing the signal level and the ground lift or bounce.

If what you say is true, I'm super confused about the electronic design....

 

[cynfab]

The real problem is that the PixHawk 2.0 uses 3.3v signalling for the PWM outputs and the ESC uses 5v signalling for its PWM inputs. Under "typical" conditions this will work, but with the extreme amounts of noise generated under high motor acceleration, the problems occur. The Pixhawk 2.1 solves this issue by using 5V signalling for its PWM outputs. In addition, the PWM driver in the PixHawk 2.1 is "stronger" than the one in the PixHawk 2.0 so is able to provide more drive current. This problem was identified by the 3DR PixHawk designers and solution proposed for a revision of the PixHawk. It even says that this an URGENT fix in the notes on the schematic. 3DR management chose the dirty software hack as it would let them ship all their current production PixHawk 2.0 based Solo's. As a result, ArduCopter development continued without 3DR and the firmware diverged to the point of requiring a significant effort to bring Solo back into the fold. Without, however, the dirty software hack. Thus requiring a PixHawk 2.1 to safely run mainline ArduCopter.
Edit--->Above references to PixHawk 2.1 should be PixHawk 2.1 Green---

 

[Pedals2Paddles]

Also, 3.3v signalling for ESCs is the standard. That's what everything uses and that's what SHOULD work properly on the solo. It's what every APM, Pixhawk, Pixhawk 2, Pixhawk 2.1, DJI, Hobby King, etc etc autopilot uses. It's what works properly on every ESC out there, except the defunct flawed Solo ESCs. Since the Solo ESCs have this ground bounce problem, the only way to safely 100% mitigate it is to use 5v signalling instead. The ground bounce is still there, but it drops to about 4 volts instead of the deadly 2.3v cut off point. The only reason the Pixhawk 2.1 has the 5 volt signalling option is because of the Solo. Literally nothing else requires 5 volt signalling on the ESCs. But ProfiCNC had it built into the Pixhawk 2.1 so it for this purpose. On the black 2.1 cubes, there is a solder trace you can use to change it from 3.3 to 5 volt. The green cubes come from the factory set for 5 volts specifically for the solo.

As @cynfab said, 3DR management chose not to use the 5v pixhawk redesign. And the chose not to redesign and replace the ESCs. Instead they made the developers put that slew rate hack in the firmware to sort of mostly prevent it from happening.

 

[Saijin_Naib]

Also, 3.3v signalling for ESCs is the standard

Would 5v signaling be problematic outside of a Solo for a custom build with standard ESCs?

 

[cynfab]

Depends on your ESC's, The Signalling voltage should match the controller and the ESC's.
The PixHawk 2.1 has 3.3V signalling The PixHawk 2.1 Green has 5V signalling. Both can be changed to either 3.3V or 5V by changing a jumper inside.

 

[hackbard23]

i´m in the automotive electronic industry and literally every PWM and digital signal is made with an open collector output and a pull up resistor on the input side, amplitude is not important in this configuration, voltage comes from the input side
don´t know why this is not used in the UAV industry ?

 

[Pedals2Paddles]

Would 5v signaling be problematic outside of a Solo for a custom build with standard ESCs?

Nope. ESCs are designed to be connected to an autopilot or directly to an RC receiver. And RC receivers use 5 volt signalling. So any ESC should be fine with either level.

 

[dneelands]

What processor do our ESCs use?