Shop our Airplanes Products Drone Products Sales
Thread Tools
Apr 29, 2017, 10:21 AM
Registered User
Discussion

**Idea** ProShot.. Another digital protocol.




This idea came about after watching a few youtube videos relating to DShot noise issues/capacitors/desyncs etc..

But first, let me highlight some points about Dshot..
So basically Dshot600 and DShot1200 is a stream of 16 pulses and some pulses are less than 500nS in width. The '1' is determined by a wide pulse and the '0' is determined by a narrow pulse. These pulses represent a binary number "0b0000 00000 0000 0000" to '0b1111 1111 1111 1111', which form a digital packet with 11 bits for throttle, 1 bit for padding, and the 4 bits as a CRC. The same (above) packet can be represented in hexadecimal "0xFFFF".

Any signal capacitors need to be removed the pulse widths fall above the RC filters cut-off frequency (pulses are very narrow).

Issue 1: Signal caps need to be removed. Makes the signal line extremely susceptible to noise. (FET switching causes a sh*tload of noise).
Issue 2: Slower/non-DMA based CPUs (like the typical BLHeliS CPU) suffer because capturing and processing noise uses a shitload of CPU overhead.
Issue 3: Desyncs. Motor commutation performance is compromised. Increased jitter with Phase timing (reducing efficiency and causing more current ripple).

Also Note.. Dshot is transferred though a base-2 (Binary) digital signal.

Some further information
The original (oneshot) signal is transferred through a pulse width. The pulse width is measured via a hardware timer counter which triggers on the rising and falling edges. Oneshot was very robust as the capacitor did a really good job filtering noise. The timer cap capture varying pulse widths with great accuracy.

"The Good stuff "
Because the HW timer capture unit can read varying pulse widths, why not transfer pure hexadecimal. We send out 4 x wider pulses (which work fine with capacitors). The pulses have a varying width from 1uS to 2.6uS. A 1uS pulse represents "0x0", and the 2.6uS pulse represents a "0xF" in 0.1uS increments. Example 0x5 is transferred though a 1.5uS pulse and a 2uS pulse represents a 0xA. We also have a 1uS gap between each pulse. When combined, these represent our original Dshot packet "0xFFFF". Jitter wont be an issue as we only detecting 16 step sizes (as opposed to 1000 steps). The signal will look like so...

Note.. ProShot is transferred though a base-16 (hexadecimal) digital signal.

Now the beauty here is..
We can have capacitors on the line.
We have the 11bits of digital data.
We have CRC.
We have Less CPU utilisation as its only capturing 4 x pulses as opposed to 16 pulses.
And its faster!! The total packet width is (2.6uS + 1uS) x 4 = 14.4uS... Therefore theoretical 69.444KHZ

Youtube link explaining the signal:
ProShot vs Dshot600 comparison. (4 min 18 sec)


Attached picture shows what the Proshot signal looks like.
Thoughts?
Last edited by Ub3r; Jun 07, 2018 at 09:56 AM.
Sign up now
to remove ads between posts
Apr 29, 2017, 08:27 PM
AKA jflyper
I think you have to add a framing protocol with error detection.
Apr 30, 2017, 02:03 AM
Registered User
Quote:
Originally Posted by teralift
I think you have to add a framing protocol with error detection.
Has framing and error detection. The framing is exactly like Dshot.. 11bits for throttle, 1 for telemetry rq, and 4 bits for CRC.
See every Proshot pulse represents 4 bits of data, so effectively the entire last pulse is a CRC.

ProShot transfers the same DShot digital data, just in a different way.
It allows the cap to stay and allows for a faster and more robust transmission.
Apr 30, 2017, 02:18 AM
Crash specialist
pFrancisco's Avatar
This is why I love this hobby.
Apr 30, 2017, 05:42 AM
Registered User
Some more food for thought... I have pointed this out in the blheli thread. The esc's are updating the PWM duty cycle to the motors at 24khz and maybe a bit higher for some esc's.
Synchronization of the control signal with the esc PWM frequency should reduce the latency. Right now this is happening.

For example if you feed an esc a digital signal at 36khz to and esc updating the motors at 24.
1)signal sent to esc,
2)at the end of PWM cycle the new duty cycle is set. This does not change once set.
3)during the next cycle 2 signals are sent to the esc.
4)esc sets duty cycle on the last signal it recieved, this one has a shorter latency (time.between signal and duty cycle set)
5)during the next cycle, one signal is recieved again, earlier in the cycle.

In simple terms the esc is setting its power once after one dshot signal .. then two.. then one.. then two.

If you were to give a smooth gradient dshot signal for example. Give imaginary numbers like 1,2,3,4,5,6,7 the esc will set that ramp like this 1,3,4,6,7. The latency will be all over the place too.

Increasing the frequency does reduce the average latency but a digital signal that is sent to the esc synchronized to PWM can be immediately converted to duty cycle will have not only a shorter latency but also consistent latency.

Does this matter, who knows?

To me, there is no point to any control signal to the esc faster than PWM frequency as the esc only sets it's power at 24khz.
Apr 30, 2017, 06:00 AM
Registered User
Or send one nibble (4 bit group) with a timed high pulse, and the next with a timed low pulse, and repeat. That means no need to have the fixed 1us gap. Even faster.

Steve
May 04, 2017, 07:59 AM
Registered User
Quote:
Originally Posted by Steve Evans
Or send one nibble (4 bit group) with a timed high pulse, and the next with a timed low pulse, and repeat. That means no need to have the fixed 1us gap. Even faster.

Steve
Hi Steve,
If you do that you need to reconfigure the timers at every pulse and its a pain in the ass doing it like that using the DMA channel.

Gents,
Ive just uploaded a video comparison of the ProShot and Dshot signals. Hopefully its easier to understand now
ProShot vs Dshot600 comparison. (4 min 18 sec)
May 05, 2017, 06:10 AM
Registered User
How about people stop catering to 8-bit FCs and ESCs?! That stuff needs finally to die.

While suboptimal, DShot is sufficient. People ought to be using CAN, SPI or whatever to begin with. But woe us thanks to crappy cheap ESCs. And also that idiotic 32KHz craze.

Also, all those silly highly paid engineers designing digital buses probably have a reason to keep it strictly binary.
May 05, 2017, 06:35 AM
Registered User
Quote:
Originally Posted by Glowtape
How about people stop catering to 8-bit FCs and ESCs?! That stuff needs finally to die.

While suboptimal, DShot is sufficient. People ought to be using CAN, SPI or whatever to begin with. But woe us thanks to crappy cheap ESCs. And also that idiotic 32KHz craze.

Also, all those silly highly paid engineers designing digital buses probably have a reason to keep it strictly binary.
The benefits will also be seen on 32bit ESCs.
The Dshot dataframe itself is great, however i think there are benefits to be had in the way that frame is transmitted.

Keep in mind..
CAN requires a differential pair line and canbus transceiver. Not good for ESCs on a budget.
SPI requires a CLK, Data, GND lines. Therefore 3 wires. Itll also require a chip select wire if the frame doesn't contain addressing.

BTW i agree with you that 32Khz is ridiculously more than enough, however main benefit here is the more robust comms with lower CPU overhead.
May 05, 2017, 08:01 AM
Registered User
What benefits are there with DMA capture?
May 05, 2017, 08:10 AM
Team AlienWarpSquad
This is an interesting Idea and Protocol BUT:
this is NOT strictly a Digital protocol- It is ANALOG encoding of Digital values and a Slight Glitch can cause a Huge Error if not caught and Ignored by the CRC.
May 05, 2017, 08:35 AM
Registered User
Quote:
Originally Posted by Ub3r
CAN requires a differential pair line and canbus transceiver. Not good for ESCs on a budget.
The trend of compromising on control and signaling just to save a buck is a trend that annoys me like there's no tomorrow anyway. One of the reasons we're still running 8-bit ESCs for the most part.

--edit: also telemetry seems to be all the upcoming rage, so you need a second wire per ESC anyway, might as well do CAN and send data bidirectional.
Last edited by Glowtape; May 05, 2017 at 09:11 AM.
May 16, 2017, 01:04 PM
Registered User
Quote:
Originally Posted by Ub3r
The pulses have a varying width from 1uS to 2.6uS. A 1uS pulse represents "0x0", and the 2.6uS pulse represents a "0xF" in 0.1uS increments. Example 0x5 is transferred though a 1.5uS pulse and a 2uS pulse represents a 0xA. We also have a 1uS gap between each pulse.

Attached picture shows what the Proshot signal looks like.
Thoughts?
Since we are back to measuring pulse width, does it mean we are back to ESC calibration again?
May 17, 2017, 01:32 AM
Registered User
Quote:
Originally Posted by Klizmatron4ik
Since we are back to measuring pulse width, does it mean we are back to ESC calibration again?
Because the quantization steps in the pulses are so large (only 16 steps per pulse), calibration wont be required.
Dshot is also measuring a pulse width BTW. Only difference is that Dshot has 2 x states per pulse. Proshot has 16 states.
May 17, 2017, 04:12 PM
nerd
AndWho's Avatar
Yes of course this is digital information being transferred. Same as Dshot. The difference is that dshot carries 1 bit per symbol (pulse), i.e. bit rate is equal to symbol rate, while with this proposal you would have 4 bits per symbol. Bit rate is four times higher than the symbol rate.

This is really nothing new, has been in use for decades in telecom. There are all sorts of coding and modulation schemes with varying bit vs symbol rate. Take the common 64QAM for example, 6 bits per symbol. Read more https://en.wikipedia.org/wiki/Symbol_rate
/A


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
New Product Dshot - Digital Protocol for Flyduino KISS FCs and ESCs flyduino Multirotor Drone Electronics 400 Jan 16, 2018 08:11 PM
Discussion Yet another tranmitter protocol question. Rutabaga Mini Multirotor Drones 1 Jun 19, 2013 05:41 PM
Discussion Walkera protocol the same as anylink protocol? Roeland54 Mini Multirotor Drones 1 Oct 13, 2012 09:19 AM
Discussion Digital servo protocol Tom Harper DIY Electronics 13 Feb 14, 2008 03:40 PM
Hitec digital servo protocol Inconel_601 DIY Electronics 17 Aug 05, 2006 02:49 PM