Thread Tools
Nov 25, 2015, 11:47 AM
I'd rather be flying
QuadMcFly's Avatar
Quote:
Originally Posted by RS2K
That's an interesting idea. SPI can work that way and fast enough ESCs could offload some work from the FC. It would require some interesting protocols to make happen.
Would require more wires though, yes? Also, whenever you increase the speed of communication, electrical noise and interference becomes a much bigger issue. A quad is by nature a super noisy environment, so I can see some potential problems there that will need to be overcome.
Sign up now
to remove ads between posts
Nov 25, 2015, 12:02 PM
Woohoo!
RS2K's Avatar
Thread OP
Quote:
Originally Posted by QuadMcFly
Would require more wires though, yes? Also, whenever you increase the speed of communication, electrical noise and interference becomes a much bigger issue. A quad is by nature a super noisy environment, so I can see some potential problems there that will need to be overcome.
Yes, the noise is a big problem here. SPI needs a bare minimum of two lines. Three if you want to use SS, and four for two datalines.

An SPI ESC bus can be done with two lines, but it would be interesting trying to figure out how to get it to work reliably.

Running SPI at 1ish MHz would be an improvement over PWM. I need to test to see if this will be practical.
Nov 25, 2015, 12:19 PM
Team AlienWarpSquad
If you want to run very high speed data lines in a noise environment then use fully Differential signals. I do this with designs I do at work when data speeds get above 50-60MHz.

This does require more wires but has very good noise immunity.

As for SPI to ESCs, one could design a Protocol with Address and Data values. Then Two wires (data & clock) plus ground to all ESCs. The ESCs would need to have an Address set in them so they only respond to data address to them.

How fast do we need the sensors and PID loops running? No one yet knows. Go back a year and everyone was saying that Flyduino's OneShot was useless and would not improve performance. We all know how wrong that thinking was.

Back two years and 3500usec Looptime was considered fast enough for any copter. Again proven to the wrong.

So to keep pushing what the FC and ESCs might be able to do is worthwhile since no one really knows yet where the limits may be. So keep up the innovations.
Nov 25, 2015, 12:52 PM
Woohoo!
RS2K's Avatar
Thread OP
Quote:
Originally Posted by waltr
If you want to run very high speed data lines in a noise environment then use fully Differential signals. I do this with designs I do at work when data speeds get above 50-60MHz.

This does require more wires but has very good noise immunity.

As for SPI to ESCs, one could design a Protocol with Address and Data values. Then Two wires (data & clock) plus ground to all ESCs. The ESCs would need to have an Address set in them so they only respond to data address to them.

How fast do we need the sensors and PID loops running? No one yet knows. Go back a year and everyone was saying that Flyduino's OneShot was useless and would not improve performance. We all know how wrong that thinking was.

Back two years and 3500usec Looptime was considered fast enough for any copter. Again proven to the wrong.

So to keep pushing what the FC and ESCs might be able to do is worthwhile since no one really knows yet where the limits may be. So keep up the innovations.

You're spot on about how history has gone. I won't be done with looking for innovations in speed and latency until we find that limit.

Address and data is exactly what I was thinking. To use SPI as a bus without SS, each ESC can be assigned a number based on its serial number. The problem is how do we find the ESC's serial number at startup without data collisions. I was thinking we could use a counter along with the chip's serial number after a "report" signal was sent from the ESC to find which ESC is which. The problem there is counting up 96 bits would take forever.... almost literally (over 100 billion years on a 48 MHz chip). I was thinking about using the serial number to as a way to encode several report attempts. At 1 MHz we could easily do over 1000 reports per second so I don't think this would be a very big problem.
Last edited by RS2K; Nov 25, 2015 at 12:59 PM.
Nov 25, 2015, 01:08 PM
Woohoo!
RS2K's Avatar
Thread OP
At 20 MHz, an 8 bit throttle signal could be sent in under 1 Ás (2,380 KHz max). That would require SS to happen that fast. If you include an address that would allow for 8 ESCs you would require (8+6)*6 bit. 84 bits.

84 bits at 20 MHz would require 4.2 Ás to transfer (238KHz max). That allows plenty of time for information from the ESCs to get back to the FC over the same line since commutations take a significant amount of time to occur at data rates that high . After the throttle data is sent the FC can ask for telemetry from any ESC it wants based on its address.
Nov 25, 2015, 01:12 PM
SiieeFPV
extent's Avatar
Quote:
Originally Posted by RS2K
I'd like to know how fast a prop can accelerate in 1 RPM from hover speed.
From my initial tests with [email protected] I was seeing timescales for idle to full accel and decel around 200 - 300ms, you only get really impressive looking numbers if you ignore your actual targets and start saying "close enough" I can't wait for QMF to start looking at breaking numbers to try to duplicate them.

from idle +3k rpm/rotation, around hover +300 rpm/rotation
Nov 25, 2015, 01:16 PM
Woohoo!
RS2K's Avatar
Thread OP
Quote:
Originally Posted by extent
From my initial tests with [email protected] I was seeing timescales for idle to full accel and decel around 200 - 300ms, you only get really impressive looking numbers if you ignore your actual targets and start saying "close enough" I can't wait for QMF to start looking at breaking numbers to try to duplicate them.

from idle +3k rpm/rotation, around hover +300 rpm/rotation
I'd imagine a more powerful combo on higher voltage would be quite a bit faster, and while it's a very interesting number (One I really want to know ), I also know hover to full throttle isn't a very useful number in the real world. Stabilization is going to use much smaller throttle changes nearly all the time. Something like 50% to 55% speed numbers are going to be more useful for the real world.
Nov 25, 2015, 02:45 PM
Team AlienWarpSquad
Quote:
Originally Posted by RS2K
At 20 MHz, an 8 bit throttle signal could be sent in under 1 Ás (2,380 KHz max). That would require SS to happen that fast. If you include an address that would allow for 8 ESCs you would require (8+6)*6 bit. 84 bits.

84 bits at 20 MHz would require 4.2 Ás to transfer (238KHz max). That allows plenty of time for information from the ESCs to get back to the FC over the same line since commutations take a significant amount of time to occur at data rates that high . After the throttle data is sent the FC can ask for telemetry from any ESC it wants based on its address.
Yea, working out the protocol is the hard part.

I was thinking more on the lines of Assigning an Address to the ESCs during a Setup. Then 4 bits of address would be enough for 14 ESCs (need to save either '0' for none and 'f' for All).
Maybe during setup One ESC is connected at a time then use a "write Address command. Since most SPI controllers work on Bytes there can be a Command/Address byte (4 command bits and 4 address bits). Then 8 bits of Throttle data or data "payload".

The other part of this is making it easy to get each ESC addressed to the correct Arm of the copter. My guess is a diagram in a GUI would be used.

The 4 command bits could also be used for reading back info from the ESCs, the MSb is a read/write bit then 3 bits for 8 commands on read and write.
Address 'All' could be used for Arm (min_throttle) & Motor Stop/Disarm.

So with a 20MHz SPI clock (50nsec per bit) and 16bits per ESC, all escs can be written to in:
3.2usec for a Quad, 4.8usec for a Hex and 6.4usec for a Octal
Nov 25, 2015, 04:00 PM
Woohoo!
RS2K's Avatar
Thread OP
Quote:
Originally Posted by waltr
Yea, working out the protocol is the hard part.

I was thinking more on the lines of Assigning an Address to the ESCs during a Setup. Then 4 bits of address would be enough for 14 ESCs (need to save either '0' for none and 'f' for All).
Maybe during setup One ESC is connected at a time then use a "write Address command. Since most SPI controllers work on Bytes there can be a Command/Address byte (4 command bits and 4 address bits). Then 8 bits of Throttle data or data "payload".

The other part of this is making it easy to get each ESC addressed to the correct Arm of the copter. My guess is a diagram in a GUI would be used.

The 4 command bits could also be used for reading back info from the ESCs, the MSb is a read/write bit then 3 bits for 8 commands on read and write.
Address 'All' could be used for Arm (min_throttle) & Motor Stop/Disarm.

So with a 20MHz SPI clock (50nsec per bit) and 16bits per ESC, all escs can be written to in:
3.2usec for a Quad, 4.8usec for a Hex and 6.4usec for a Octal
That's a good idea. Taking that a little farther, during setup a setup command could be sent to all ESCs. At that point you can designate motor direction and number by rotating the motor cans.

Quad setup Setup:
1. Ensure all ESCs and motors are connected and ESCs are powered up. FC sends setup command to ESCs. ESCs wait for rotation.
2. Rotate motor 1 in the proper direction. (ESC 1 then send its serial number to the FC for address assignment while saving the prop direction) (FC sends address to ESC with that serial number) (ESC chirps the motor for verification)
3. Rotate motor 2 in the proper direction. (ESC 2 then send its serial number to the FC for address assignment while saving the prop direction) (FC sends address to ESC with that serial number) (ESC chirps the motor for verification)
4. Rotate motor 3 in the proper direction. (ESC 3 then send its serial number to the FC for address assignment while saving the prop direction) (FC sends address to ESC with that serial number) (ESC chirps the motor for verification)
5. Rotate motor 4 in the proper direction. (ESC 4 then send its serial number to the FC for address assignment while saving the prop direction) (FC sends address to ESC with that serial number) (ESC chirps the motor for verification)


A digital signal won't need any calibration other than that. 0000 0000 is off, 0000 0001 is idle 0000 00010 - 1111 1111 is your throttle. Idle speed can be calibrated per ESC if we need to. I don't think we'll need more than 253 steps of throttle, but it'd be very easy to add more bits to the stream to get as many throttle steps as we want (16 bits would give 65,535 throttle steps). I think we should use parity as well. The speeds are going to be plenty fast. If an ESC gets bad data it can request a resend within a set period of time based on how many ESCs there are. Or it can include a bad data flag in its telemetry stream.

RPM data, Current and voltage can be directly measured on each ESC. This will allow for trouble shooting and we can calculate the load on the motor.
Last edited by RS2K; Nov 25, 2015 at 04:13 PM.
Nov 25, 2015, 05:15 PM
Registered User
SystemsGuy's Avatar
Quote:
Originally Posted by RS2K
That's a good idea. Taking that a little farther,
<snip>
RPM data, Current and voltage can be directly measured on each ESC. This will allow for trouble shooting and we can calculate the load on the motor.
And we're back where we started, aren't we? If you are going to redo it, just make it bidirectional and go closed loop.
Latest blog entry: FrSky Long Range!
Nov 25, 2015, 05:19 PM
I'd rather be flying
QuadMcFly's Avatar
Quote:
Originally Posted by SystemsGuy
And we're back where we started, aren't we? If you are going to redo it, just make it bidirectional and go closed loop.
+1, Isn't that the end goal of all of this anyway?

Also, I come from an audio background, so differential signals (we called it balanced) makes sense to me!
Nov 25, 2015, 08:33 PM
Registered User
CAN is differential by design. SPI doesn't include an addressing scheme in the protocol, rather it uses slave select lines (so it's more efficient as there's no device addressing overhead).
Quote:
Originally Posted by RS2K
It's great to see testing like this! I did some basic bit shifting to test 8 KHz on BLHeli a while back and ended up with around 100 or so steps of resolution . An RCP_ALIAS_SHIFT of 8 would give a maximum of 50 steps of useful information. How much resolution is lost when going from a default of 3 to 5?
BLHeli has a lot less steps than SimonK even with current signal widths.
Nov 25, 2015, 08:55 PM
Woohoo!
RS2K's Avatar
Thread OP
Quote:
Originally Posted by SystemsGuy
And we're back where we started, aren't we? If you are going to redo it, just make it bidirectional and go closed loop.
Quote:
Originally Posted by QuadMcFly
+1, Isn't that the end goal of all of this anyway?

Also, I come from an audio background, so differential signals (we called it balanced) makes sense to me!
That's the plan.
Nov 26, 2015, 11:41 AM
Woohoo!
RS2K's Avatar
Thread OP
I've got the first version of Multishot (analog) running with Raceflight. I need to add in a bit of sanity before it's ready for testing.
Nov 26, 2015, 12:55 PM
Woohoo!
RS2K's Avatar
Thread OP
Quote:
Originally Posted by tracernz
CAN is differential by design. SPI doesn't include an addressing scheme in the protocol, rather it uses slave select lines (so it's more efficient as there's no device addressing overhead).

BLHeli has a lot less steps than SimonK even with current signal widths.

That's easy enough to fix by changing the PCA0 divider base (For SiLabs at least).

256 steps works very well at these high frequencies. No reason to work with 16 bits on an 8 bit MCU if we can avoid it. 32 bits will resolve this issue in the end. I'm not sure we can get around capturing the signal at 16 bits though.

MultiShot v1 is aimed at performance, and the newest generation of SiLabs ESCs are considerably better than the Atmel based ESCs. SimonK also works with Atmel better than BLHeli does. For those resons, MultiShot v1 on BLHeli will be for SiLabs only... at least for now.


Quick Reply
Message:

Thread Tools