Does pulses_get function have a 200 bit limitation when reading?

[robert-hh]

@Pesien Digging a little bit further I found the place. It is indeed a limited number events, defined by line 59 of modpycom.c
rmt_driver_install(RMT_CHANNEL_0, 1000, 0);
1000 is the size of the ringbuffer, with 4 bytes per event. So if you want more, increase that number and rebuild the firmware.
The hint for that is here: https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/rmt.html
Edit: Testing with a square wave generator returns 128 pulses, which is less than expected from the explanation above, but the same number you have seen.
Edit2: Increasing the number above does not change anything.

[Pesien]

@robert-hh Thank you so much for the help, really. I'll try to understand how I can fix it tomorrow when I have some time.
Edit: Even though it was not a fix, thank you for your help. Also you confirmed me it was not my code only.

[robert-hh]

@Pesien See below: It was'nt a fix.

[Pesien]

@robert-hh Any new ideas on why is this happening?

[robert-hh]

@Pesien I have to check further this evening. The 128 events match the 64 * 4 byte RAM buffer page dedicated to each RMT channel. That should be copied to the ringbuffer to avoid overrung of the RMT RAM, but somehow that does not happen. Trying to assign more than one RMT Buffer page to a channel failed.

[crumble]

@Pesien said in Does pulses_get function have a 200 bit limitation when reading?:

@robert-hh Any new ideas on why is this happening?

According to the link from @robert-hh this function is part of an API whicht deals with infrared remote controls. They send/receive usualy only short messages.

[robert-hh]

@Pesien No luck with simple hacks. Also machine.RMT offers no better choices. But in documentation there the 128 entry limit is mentioned. I do not know whether this is a limitation of the underlying RTOS or the way the pycom firmware uses it.

[Pesien]

@robert-hh Then I guess I'll have to try again with interrupts and timers...
Thank you for your help again, and if you know any better solutions for pulse reading i'd love to hear them.

[jcaron]

@Pesien According to the documentation, you can configure the UART to use only one pin if you are only receiving. Just state None as the TXD pin and you should be all set.

[robert-hh]

@jcaron Well, but@Pesien wnat to send AND receive in hald-duplex mode. But it may be possible to switch between send & receive. The only problem would be to find the right time, because the send() returns before the data actually has been transmitted.

[jcaron]

@robert-hh Ah indeed, had only seen discussion about receiving data, but I now see that the protocol implies data in both directions.

One may try to give the same pin for both RXD and TXD, maybe? Not sure if the ESP32 would support that. There would probably be "echoing" of sent data if it were the case, though.

Otherwise the timing issue should be pretty simple. 1200 bits/s, 7 bits, parity, probably one start, one stop, that means 120 characters per second.

[robert-hh]

@jcaron I made a little bit of testing. It seems that you can a single Pin between TX and RX, by re-doing the uart init or instantiation between send and receive with the option pins=(pin, None) and pins=(None, pin) for send and receive. That switch takes 600-800 µs, about 1 bit duration. There are some hiccups involved.

• The other side must not send any characters before the switch from TX to RX has happened. Otherwise, the receiver will lock up and will not detect anything for about 3 seconds (maybe 32 characters, t.d.a.).
• The Pycom device must wait with switching until all characters have been sent. Otherwise the message will not be sent.

So its a little bit of tricky timing, which works best if the sensor is a slow responder. But I read that in SDI-12 the sensor must respond within 15 ms. uart.wait_tx_done() may be appropriate for the wait.

[jcaron]

@robert-hh did you by any chance try to use the same pin for RX and TX? I would be surprised if that worked, but you never know...

[robert-hh]

@jcaron Yes. That was indeed the intention of the test - using the same pin for send and receive. To some extent it worked, with a strange glitch:
If in the process of switching the pin from send to receive characters for receive arrive too early, the receiver locks up for a while. I could not determine with my simple set-up, whether it locks up for a certain time (2-3 seconds or ~250 character times at 1200 baud) or for some number of characters, which are dropped. My gut feeling says it's the latter, and has something to do with the receive ring buffer. But I did not look into the code yet, and it is surely tricky to make a proper test set-up.

[robert-hh]

@jcaron The test code used for that was;
LoPy4 test code:

from machine import UART
from time import ticks_us, ticks_diff, sleep_ms
msg = "cccccccc\n"
def run():
    uart=UART(1, baudrate=1200, pins=("P3", None))
    sleep_ms(5000)
    for _ in range (3):
        uart.write(msg)
        print(uart.wait_tx_done(int((len(msg) * 8.333)) + 10))
        uart.init(baudrate=1200, pins=(None, "P3"), timeout_chars=20)
        print(uart.readline())
        uart.init(baudrate=1200, pins=("P3", None))

run()

PC test code (Lopy4 connected to PC with a USB/Serial adapter, both RX and TX of that adapter connected to LoPy P3:

import serial

ser = serial.Serial("/dev/ttyUSB2", 1200)

while (True):
    while True:
        line = ser.readline()
        print(line)
        if (b"ccc" in line):
            break
    print("Send Echo")
    ser.write(b"Response\n")

Edit: That test code works fine. Trimming is required for the wait time after sending the command.
Edit2: Actually it's not that difficult. The specified wait time just has to be long enough, because the call returns as soon as the message has been sent (or after the wait time, if that is earlier).

[jcaron]

@robert-hh sorry, I meant using the same pin as both TXD and RXD when configuring the UART. Probably not allowed by the internal mux, but you never know.

[robert-hh]

@jcaron I just tried that. Even if you get no error message, no data is sent.

[Pesien]

@robert-hh I got it working with time.sleep_us, but I have a new problem. When I read the sensor 6-7 times the timers stop working properly, and the more I read it, the worse it gets. It feels like the timers are not reseting when the board does.
However, manually reseting the board or forcing at the end of the code a power reset fixes it.
Here is the code, and I'll really appreciate any help you can give me about this problem.
(The code works reading the pin every 833 us, which is the duration for 1 bit, and storing the value in a list to translate it later. The timer at the end is not 833 because I had to take into acount the time the chip needs to run the code before it.)

        self.pin_unico=Pin(Pin_SDI12, mode=Pin.IN, pull=Pin.PULL_DOWN)
        self.lista_bits=[]
        self.lista_bytes=[]
        while True:
            if self.pin_unico()==1:
                break
        self.lista_bits.append(1)
        time.sleep_us(833)

        while True:
            self.lista_bits.append(self.pin_unico())

            if len(self.lista_bits)==10:
                if self.lista_bits==[0,0,0,0,0,0,0,0,0,0]:
                    #self.lista_bytes.append(self.lista_bits)
                    self.lista_bits=[]
                    break
                else:
                    self.lista_bytes.append(self.lista_bits)
                    self.lista_bits=[]
            time.sleep_us(777)

The correct answer for the identification command for this sensor is:
013DECAGON MPS-6 386889208069\r\n
(I get this the first 6-7 times)
Then I get this results:
013DECAGON MPS-6 38688920807FSFENQ (7th time)
013DECAGON MPS-6 3868[FSYCAN[CANESCFSFENQ (8th time)
013DECAGONP&()SYNESCPEM[ESC[[NlLnLMNcB (9th time)

And so on. As you can see the reading is incorrect because there is some kind of problem with the timers, but the only way I found to solve this was to power reset the board.

[robert-hh]

@Pesien Long long ago i made a UART read by pit probing. As far as I recall, the software:

• waited for the start bit transition, and then
• probed the value in the middle of the following bit frames.

I see no reason why your approach would deviate over time. Expept that the time for append increases. So for the 7 bits of a byte I would preallocate a bytearray of 7 bytes, or just shift that into a single int value. Something like:

        EOL = const(0x0a) # end of line
        self.lista_bytes=b''
        
        while True:
            bits = 0
            while True: # wait for the start bit
                if self.pin_unico()==1:
                    break
            time.sleep_us(1200) # wait for a 1.5 bit times
        
            for bit in range (8): # get the next 8 bits
                bits = (bits << 1) | (1 - self.pin_unico())
                time.sleep_us(800) # to be determined, about a bit time
            bits >>= 1
            self.lista_bytes += bits.to_bytes(1, "little")
            if bits == EOL: # maybe \n or 0x0a
                break
# now msg contains a list of bytes with the response

Edit: If the lowest order bit is sent fist, then the inner loop may be:

            for bit in range (8): # get the next 8 bits
                bits = (bits >> 1) | ((1 - (self.pin_unico()) << 8)
                time.sleep_us(800) # to be determined, about a bit time

and the shift after the loop can be omitted.

[Pesien]

@robert-hh Thank you. I'll try to preallocate an array of bytes before reading and the 1.5 initial bit time and will update with the results.