Does pulses_get function have a 200 bit limitation when reading?

[Pesien]

@robert-hh Thank you again for all your help. I'll try it tomorrow and see if it works finally.

[robert-hh]

@Pesien Just for interest I tried to set up an interrupt based version where:

• the start bit would trigger a pin interrupt callback, which then
• fires a series of n timer callbacks to read the bits of each byte.

Even if the software itself worked, that attempt failed because:

• the callback latency of the pin interrupt is greatly varying between 100µs and ~1000µs, making it impossible to sync on the first bit.
• the shortest period of a sequence of timer interrupts is about 2 ms. 0.883 ms would be needed for 1200 baud.

Even if the timer based bit probing is replaced by the active waiting method, the initial pin interrupt latency prevents reliable reading.

[robert-hh]

@Pesien I tried this interrupt mechanism with the microypthon.org branch of MicroPython. That works better. Only the first character in a message is disturbed after a longer (few seconds) break between messages. This glitch is caused by the timer burst delayed by ~500µs. The reason for that should be the relevant code not being in the memory cache and having to be imported from serial flash. This code page fetch takes at least 300µs.

[Pesien]

@robert-hh Finally I got some time to work on this. I tried your solution, but for some reason it simply does not work.
However, I managed to get it working with the next code:

def read(self):

        
        self.pin_unico=Pin(Pin_SDI12, mode=Pin.IN, pull=Pin.PULL_DOWN)
        self.lista_bits=[0,0,0,0,0,0,0,0,0,0]
        self.lista_bytes=[None]*50
        y=0



        while True:
            while True:
                if self.pin_unico()==1:
                    break
            time.sleep_us(390)
            time.sleep_us(390)
            time.sleep_us(390)
            self.lista_bits[0]=1


            for x in range (0, 8):
                self.lista_bits[x+1] = self.pin_unico()
                time.sleep_us(814)


            self.lista_bits[9]=0
            #print(self.lista_bits)

            if self.lista_bits==[1,1,0,1,0,1,1,1,1,0]:
                self.lista_bytes[y]=self.lista_bits
                self.lista_bits=[0,0,0,0,0,0,0,0,0,0]
                break
            else:
                self.lista_bytes[y]=self.lista_bits
                self.lista_bits=[0,0,0,0,0,0,0,0,0,0]
                y+=1
                #print(self.lista_bytes)

        #print(self.lista_bytes)
        
        return(self.lista_bytes)

The thing is that it only works the first time (first byte) and it gets stucked here the second time:

while True:
    if self.pin_unico()==1:
        break

I don't know why this is happening. It makes no sense to me.
Edit: I just tried it and your code has the same issue but I cant make it work even the first time.

[robert-hh]

@Pesien The timing is essential. You have to wait for the next byte in the time frame between the last bit of the previous byte and the start bit of the next byte. That time frame may be as short a one bit duration (883 µs). If you miss the transision of the start bit, all timing is disturbed for a byte and all subsequent bytes. The code you have at the end of a byte seems to be too slow.
Yind you have an oscilloscope, you can try to monitor the state of your code in relation to the incoming data, liek I did with the monitor pulses. A sequence debug_pin(1);debug_pin(0) takes about 5 µs and will leave a visible time marking in the oscilloscope. Without such analysis capabilities it's hard to get along. I'm using a check logic analyzer tool for that, like this one: https://www.amazon.com/HiLetgo-Analyzer-Ferrite-Channel-Arduino/dp/B077LSG5P2/ref=sr_1_3?crid=3S1O51OGJW1Q2&keywords=logic+analyzer+usb&qid=1558955763&s=gateway&sprefix=logic+anal%2Caps%2C242&sr=8-3, which works nice together with the saleae logic analyzer software.

[robert-hh]

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

The other thing is about how pythone deals with objects like a list. The statement self.lista_bytes[y]=self.lista_bits does not copy the list, but just copies a reference. If you change lista_bits later on, the entry in lista_bytes will be changed too. At the end, all entries in lista_bytes will be the same. So instead of self.lista_bytes[y]=self.lista_bits, you must write:
self.lista_bytes[y]=self.lista_bits[:], which will create a copy. In any case self.lista_bits=[0,0,0,0,0,0,0,0,0,0] is not needed.

[Pesien]

@robert-hh Even if the timing is not correct, it should detect any of the following possitive bits, but it doesn't. And with the code you made, that while doesn't work even for the first bit, so I think that there is something else happening that I don't see.

[robert-hh]

@Pesien Yes. You should get some testing equipment to tell, whther the signal level arer those that you expect, and if, that you can determine in your code the high and low levels. For such kind of analysis, an oscilloscope works better than a logic anayzer, because it show also possible troubles with analog levels and transition times.

[Pesien]

@robert-hh FINALLY I managed to make it work. I'll upload the full library in a few weeks here in the forums, because I know there are a lot of people that will like to use it. It comunicates with SDI12 sensors using only one GPIO pin for sending and receiving data.

If it wasn't for your help, I wouldn't have been able to make it. I really appreciate the effort you made to help me and I'm really grateful for it.
Thank you so much.

[robert-hh]

@Pesien Congratulations. I did not try yet to set the UART in inverted polarity mode. Having already located the spots to change, I'll try that next week. Even if it is not needed for your project, it may be useful.

[robert-hh]

@Pesien @mfalkvidd
I mage a PR for inverted UART signals, based on the release candidate version. The ony changes file is mods/moduart.c, so it's easy to use it for the master branch too:
https://github.com/pycom/pycom-micropython-sigfox/pull/310