RMT update in loop problem.

[prem111as]

Hi. At the moment when I update the RMT frame of a certain channel, the frame temporarily expands, affecting other channels. I’m attaching a screenshot from the oscilloscope and the code.

MicroPython v1.14-73

`
from machine import Pin
import esp32
import globals
import time
from config import *

class PPM:
def init(self, rmt):
self.channels = [1500] * 8
self.FRAME_LENGTH = 20000
self.PULSE_HIGH = 400
self.MIN_SYNC = 2000
self._last_values = self.channels.copy()
rmt = esp32.RMT(0, pin=Pin(13), clock_div=80)
self.rmt = rmt
self.rmt.loop(True)
self._update_rmt()

def pwm_to_ppm(self, value):
    value = max(-100, min(100, value))
    return int(1500 + (value * 5))

def _update_rmt(self):
    pulses = []
    total_time = 0

    try:
        self.rmt.wait_done(timeout=1)
    except Exception as e:
        print("error in wait_done (timeout=1):", e)


    for i in range(8):
        channel = self.channels[i]
        if abs(channel - self._last_values[i]) > 400:
            channel = self._last_values[i] + (400 if channel > self._last_values[i] else -400)
        self._last_values[i] = channel
        pulses.extend([self.PULSE_HIGH, max(channel - self.PULSE_HIGH, 0)])
        total_time += self.PULSE_HIGH + max(channel - self.PULSE_HIGH, 0)


    sync_time = max(self.FRAME_LENGTH - total_time, self.MIN_SYNC)
    #if sync_time + total_time > self.FRAME_LENGTH:
    #    sync_time = self.FRAME_LENGTH - total_time  # Unikanie przekroczenia ramki
    pulses.extend([sync_time, 0])

    self.rmt.write_pulses(pulses)


def update_channels(self, updates):
    any_update = False
    for channel_name, pwm_value in updates.items():
        if channel_name in globals.ppm_channel_map:
            channel = globals.ppm_channel_map[channel_name]
            ppm_value = self.pwm_to_ppm(pwm_value)
            if self.channels[channel] != ppm_value:
                self.channels[channel] = ppm_value
                any_update = True

    if any_update:
        self._update_rmt()

def update_channel(self, channel_name, pwm_value):
    if channel_name in globals.ppm_channel_map:
        channel = globals.ppm_channel_map[channel_name]
        ppm_value = self.pwm_to_ppm(pwm_value)
        if self.channels[channel] != ppm_value:
            self.channels[channel] = ppm_value
            self._update_rmt()

def deinit(self):
    self.rmt.deinit()`

[scruss]

MicroPython v1.14-73

Maybe try with a newer MicroPython. That one is four years and more than twelve releases out of date

[mogplus88]

This looks like the same problem I'm having. I am also trying to create a PPM stream, and have found that sometimes the frames interfere with each other. It seems to me that, despite what the documentation claims, the write_pulses command does not wait for the previous frame to complete before starting to write the next frame. This seems to happen if rmt.loop() is active or not. If the write_pulses command happens to occur while a frame is being written, it just overwrites whatever was on the end of the previous frame. I think this may be a bug.
I have also found that using rmt.wait_done() doesn't seem to help.
:-(
PS in another twist, in the last few weeks I have been struggling to get anything to work at all, including stuff that used to work ages ago that I played with and forgot about (started playing with Raspberry Pi Pico, brilliant, but sadly only 3 ADCs, and Weact Blackpill, useless for ppm). I had the latest stable version of MP , 1.24.1, installed on all my ESP chips. In desperation I installed the latest nigtly, V1.25.0, and everything worked again.

Hmmm. That was last night. Tried again this morning and nothing worked again. Must be something to do with my setup rather than blaming the chip...

[mogplus88]

Well, finally found my problem. My el-cheapo Chinese knock off 8 channel logic analyser that I bought on Ebay for AUD17, failed! Well, two of the channels did, channels 0 and 1 that I use all the time. By complete accident I plugged one of the leads into channel 3 instead of channel 1, and it worked! How many hours have I wasted because of that. Don't ask.

What I have discovered, and I think this might explain it, is that the RMT blocks the next write_pulses command until it has completed sending the last pulse, not the last frame, as I had assumed.

In this screenshot the upper trace is a write_pulses executed after a fixed time (every 100ms) so there are big gaps between frames. The lower trace is the same, but with RMT.loop() activated. So the first pulse in the upper frame (arrowed) is started at the correct time. The corresponding pulse on the lower trace (arrowed) starts slightly later, as it seems to have waited for the last pulse of the previous frame to complete, not the last frame. In the documentation is refers to the last "sequence", which I assumed to be all the pulses in the "duration" mentioned in the write_pulses() command. But that doesn't seem to be what's happening.

With further experimentation I found that the best result was using a timer to trigger the write_pulses() command, with a frequency of 45. A 22.5ms frame size (which allows 8 pulses up to 2000us each plus 300us "low" pulse in between and still have a sufficiently long sync pulse at the end) which gives a frame rate of 44.4, so anything slower than 44 is going to add extra time to each frame.

Interestingly, a much faster frame rate seems to make no difference to the output. Every frame is still output, so it must be doing some serious buffering somehow, or some other trickery of which I'm totally unaware. I tried it up to a frequency of 100, and same result, all frames present and correct.

Hope this helps.

;-)

[mogplus88]

Another small fly in the ointment I've discovered. The last low pulse, the one at the end of the frame, varies.

in my program all the low pulses are 300us. I had to fudge the last one though, as it always was 325us. I solved this problem by making the final pulse length 275us instead of 300us, a horrible kludge, but it worked. (as they say in the military, if it's a stupid idea but it works, it's not a stupid idea.) But that was with the board not doing anything else. So I tried putting in some long loops that did stuff that wasn't important to see if it affected the final pulse size. Well, it did. Instead of 300us, or reasonably close to it, the last pulse is now 502us. And that's with the size set to 275 in the program.

For my application (R/C transmitter encoder for model aircraft) I'm hoping it won't matter much. When the receiver detects the sync pulse, it then waits for the next pulse and assumes it's the first one in the stream. I don't know how long it's prepared to wait for the next pulse, but hopefully more than 500us, or however long it takes to do the rest of the processing the chip needs to do. That'll be the next thing I have to play with.

:-\