That is PPM yes. I have moved this to PB7, and github is NOT up to date with this change.
2 Likes
You’re absolutely right…
About the footpad sensor for OneWheel, is that an analog input, pwm or uart or ?
Does anybody know of any cheap bluetooth that works with Vesc Tool (mobile), or is the only one working the “official” from Trampa?
Am I correct that hm10 doesn’t work with vesc tool any longer?
Today I went around on my e-skateboard in the neighborhood and tried to stress it. No problems at all so far. But I have no bluetooth right now, so yet no idea of the amount of amps put into the hardware.
I’m nearly certain the footpad switch for the OneWheel is just a dry-contact.
Does anybody know of any cheap bluetooth that works with Vesc Tool (mobile), or is the only one working the “official” from Trampa?
I’ve written my own and would be happy to share.
ETA: actually mine is not written to work with VescTool. I use bluetooth to send all the interesting data to my handheld remote, where I log in onto a uSD card.
ETA II: Actually, I’m not using Bluetooth for that anymore. I use an ESP32 on both ends, and I use the ESPNOW channel. But Bluetooth is even easier. I used to do that with an HC-05 on each end.
1 Like
It’s probably PWM and not PPM. VESC mislabels this.
Funwheel foot sensors are analog. It’s an FSR, so it would likely be set up like a voltage divider.
Yes.
Have a look over here:
4 Likes
R/C receivers output PPM. The pulse width alone determines the position and the pulse comes ever 20mSec or faster.
I’m pretty sure that’s what the VESC anticipates. I know I’m driving mine with an R/C receiver.
You say this …
But then you describe PWM.
If you look at the waveforms on an oscilloscope, they are PWM. The software also decodes them as PWM. Everything about those signals is unambiguously PWM and not PPM. They are mislabeled in VESC.
Perhaps I have the definitions reversed. But if so, I’ve had them reversed for many years. And my understanding appears to agree with that given on Wikipedia. If I’m wrong, I’d really like to learn from this.
To summarize the distinction (as I understand it)…
PWM transmits the info as a percentage of duty cycle.
PPM simply uses absolute pulse width.
1 Like
From the wikipedia current draft:
I have not seen any of this on the measured signals I’ve seen. I haven’t seen all signals in the world.
I don’t see that either, but it’s closer.
What I do see are frames containing single pulses 1ms to 2ms long, and the frame sizes I’ve seen are usually fixed at 20ms, but occasionally 20ms and 25ms, alternating between the two at 0.5Hz. I can only make a guess that the reason for this alternation is specifically to prevent the signal from being read as PPM or duty cycle. The frame size change doesn’t affect the width of the pulses but does affect their position relative to the last pulse received and also the duty cycle. Most devices I’ve seen don’t dynamically change the frame size, but some seem to.
To clarify, do you agree with my understanding that PWM is about duty-cycle while PPM is about absolute pulse-width?
1 Like
No; PWM doesn’t necessarily need to be duty cycle, though it’s important to distinguish between them because they can be different.
per the current revision at Servo control - Wikipedia
Just found out that I bought one of these a few months ago:
nrf51822 on ALI
So I’ve programmed it using this guide:
And then I will connect it to TX and RX, and it should work
1 Like
Agreed, that’s a typical application. But I thought that it was still PPM when it included just a single channel and used absolute pulse-width (rather than duty-cycle) to encode the info.
I’m now 100% confused. I’ve now found one source that says PPM pulses doesn’t vary the width at all, but only the position of the pulse in the frame. Another source (ChatGPT for full disclosure) says that PPM uses the position of the pulse to encode the data, but that the pulse-width may also change.
In any case. Let me know if we all agree that PWM is strictly a duty-cycle thing. If so, I guess I can continue to try and understand the definition of PPM better. If not - my life has been a complete lie. 
ETA: D’OH! I just saw b264’s comment: “No; PWM doesn’t necessarily need to be duty cycle”. And I certainly agree that the name alone would suggest that could be true. What now??? 
Dear friends, happy upcoming holidays and the New Year! 
@jens_overby - you did some really hard work and you are a great engineer! Thank you very much for your contribution! I wish you happiness and good luck in everything! 
1 Like
One problem with duty cycle is that achieving 0% or 100% state can frequently cause problems. A 1 - 2ms pulse in a 20+ms frame can be 0% or 100% for any length of time without affecting the decoding.
1 Like
In my experience (limited though that might be) actually using duty cycle is usually for transmitting power rather than decoding. So I would expect that to be less problematic.
1 Like
Might be fine for a OneWhell - even with low-side shunts. God bless you all in 2024.
2 Likes
1 Like