#Reading a servo - pulseio.PulseIn /

1 messages · Page 1 of 1 (latest)

ancient monolith
#

As a sanity check I hooked up an IR receiver to make sure there weren't any hardware problems. And it works fine with adafruit_irremote.
One twist is that on the scope, the signal on the pin connected to the IR receiver is inverted - i.e. it is held high except during an IR transmission. And the pulseio.PulseIn is constructed with idle_state=True, which seems reasonable? Still,

  • I can't get it to "see" any pulses from the servo PWM
  • but I can see "manual" taps in the same PulseIn instance which is missing the servo pulses
  • while successfully reading IR pulses on a separate pin
    The ESP32 supports up to 8 RMT channels at once, and if I'm reading ports/espressif/common-hal/pulseio/PulseIn.c correctly, should be configured to capture pulses between 1.25 microseconds and 65 milliseconds in length. So it ought to be able to measure 1-2msec pulses with around 6 bits of accuracy if it works like I think it does and my head math isn't too far gone
cobalt briar
#

you said the servo signal was idle low. are you setting idle_state=False when you're reading the servo signal?

ancient monolith
#

Yep - tried both ways. Tried different values of maxlen as well - IIRC there were some issues there a while back but 128 works just fine for IR.

ancient monolith
#

I don't know if the problem is on the electronics side or the signal "logical" waveform/timing

#

I have found a few "suspects" reading through PulseIn.c and the ESP32 RMT docs though. rmt_rx_channel_config_t contains an invert_in field - although I haven't seen anything specific yet about whether RMT itself cares whether the idle_state is high or low

#

rmt_receive_config_t::flags has en_partial_rx:
Set this flag if the incoming data is very long, and the driver can only receive the data piece by piece, because the user buffer is not sufficient to save all the data.

#

It may be that until it sees a "stop" - a pulse that exceeds the max length - it won't actually "report" anything

#

(without that flag enabled)

#

but I'm just guessing

cobalt briar
#

one could apply an inverted IR signal to PulseIn to see if it would detect that signal.
I'm not sure I understand why the idle_state is setting pulls and initial high/low pin state, but not setting the invert_in field you found.

#

I don't have time to look at this in detail at the moment, unfortunately.

ancient monolith
#

Don't even start worrying about it - I really ought to set this aside for now anyhow. It's very much in the "icing" category and I still need to get the cake finished.

cobalt briar
#

or could you do the inversion in PWMOut just to test?

ancient monolith
#

The PWM "Out" I'm trying to analyze with PulseIn is coming from an RC receiver - I'd have to add some kind of logic inverter circuit on the signal. Already spent more time on this than I should have (at least with my current priorities) so I might try that at some point.

#

Another not-quite-on-the-hotlist task is to create my own C/C++ extension where I can experiment with stuff like this - basically get under the hood for low level tweaking (especially ESP-IDF bits). If already had that in place, it would make answering some "what-ifs" (like changing invert_in and en_partial_rxsettings) easy

#

(I could simply modify PulseIn.c, but I'm thinking more of an "extended access" layer that exposes control over the config in CircuitPyhon code)

cobalt briar
ancient monolith
#

I think one of us is confused ... ??? I'm not generating the servo signal, it's coming from an RC receiver servo output. I'm trying to use a PulseIn to "read" (time the duty_cycle) the servo pulses. Inverting the servo signal would require some kind of circuit between the PWM output on the RC receiver and the input pin on the ESP32. I'm sure that can be done, but I don't know how (and there may be other impedance / timing / .... issues that would still be an issue even if I could). If I had an easy way to invert the signal (which I'm 99% sure I do - if only it was an old school 5V TTL signal...) I'd give it a try, but I suspect....

cobalt briar
#

you could simulate a similar servo with PWMOut and maybe invert it

#

and test both non-inverted and inverted

ancient monolith
#

I was about to say I suspect that rmt_receive_config_t::flags has en_partial_rx would still be an issue, but maybe I can test that by manually breaking the connection to the servo PWM out