Lin frame problem on Rpico

[florent314]

Hello !

first of all, thank you very much for the work accomplished for this project.

I've encounter lot of pains to make it working. My setup is a brand new CP+ along with a Combi6E. I used a Rpico W with the Lin2UART TJA1020 interface. It did not work and I spent long time to double check hardware connexions.

I finally made a small program to read UART and see something strange, I got frames like the following:
55 3c 7f 06 b2 00 17 46 40 03 27
Indeed, there was no 00 starting byte. Thus the hardware was working but software did not recognize any frame since it is waiting 00 55 !

I guess that sync_break is not recognized since in linbus protocol it should be longer (about 13 bits at 0 > 9bits (8+1stop)).
Is it a Rpico concern ? Is anybody got a similar problem ?

Then I tried to understand how the program works -that is not an easy task, great job!- and slightly modify the loop_serial function in lin.py. A serial.read() is able to read all the frame. I finally successfully registered the fake inetbox.

Would it be possible to share my code ? Maybe it would simplify a little the loop_serial function but I am not sure it will/can work on other devices.

Best regards,

PS: tell me if I can improve the manual. It would be great:

• to clarify wiring (my RJ12 wire colors seem inverted compared to available pictures ; we must connect RX pin of the lin2UART module to TX pin of the Rpico ; RX pin is TX pin of the TJA1020 ie [TX pin of TJA1020 <-> TX pin of RPico] as in the TJA1020 documentation.
• Propose a small program to test/debug hardware connexions before configuring in order to check if frames can be read.
• Give a small explanation of the format of a frame
• Give a small explanation of the process of registering the device.

[mc0110]

Your description sounds a little bit tricky. I'm not sure, the explanation will overload the descriptions. My production system is a Rpico without problems using the repo

[Tobz31]

Hey Florent,

any chance you could share your code changes? I'm currently facing a similar issue when connecting to the Truma.

BR Tobz

Update 06.12.24: Problem solved

[Deleny74]

Hey,

I have the same problem with RP Pico W2040 that the frame starts with 55 and not at 00 55.

I also flashed an ESP32. Truma detects it without any problems and it works. My only problem with the ESP32 is that it frequently loses connection and crashes after a few days.

Can you share your Code for the lin.py?

[mc0110]

Okay guys,
I'm sorry, there seems to be a problem. I suspect it is analogue to what @florent314 describes above. There seems to be a timing problem so that the RP Pico does not recognise the 0 start byte. This may be due to the in2UART TJA1020 interfaces or to the Picos. I cannot reproduce the error, my Picos recognise the start sequence. There are several ways to debug it.

1. Daniel shows a solution to use the RP3 or RP4. Here there is also the possibility to write extensive logs. https://github.com/danielfett/inetbox.py The TJA1020 interface can also be used. This allows you to check whether the start bits are recognised there.
2. the decoding of the sequences only takes place in the lin.py module and there in the loop_serial function. Here you can see if you can modify it.
3. @florent314 provides us with his patch

I'm sorry that I can't solve the issue myself, but the problem was first made known by @florent314. There may have been an adjustment to the RP Pico in hardware or MicroPython.

[mc0110]

@Tobz31 can you give us a hint how you solved the problem?

[florent314]

Dear all, I would be glad to help... Due to lack of time I did not try it anymore. But at that time it worked.
I would be happy if someone can teach me how to propose a patch in GitHub.

Here is the beginning to my loop_serial function :

async def loop_serial(self):

        self.status_monitor()        
        # New input process: idea is, nothing to forget. So there is a turing-machine nessecary. This read 1 byte and decide to switch in the next level or to throw the input away
        # So there is a much higher probability for synchronizing
        if not(self.serial.any()):
            return
        self.pin_map.dtoggle_led("lin_led")
        #line = self.serial.read()
        ##if self.loop_state: # this means level 2
        ##    if line[0] == 0x55: # here it is clear, we saw a correct synchronizing
        ##        line = bytes([0x00, 0x55]) + self.serial.read(1)
        ##        self.loop_state = False
        ##        # this is the exit point of the turing machine
        ##    else: # recycling the byte, if it is 0x00 
        ##        self.loop_state = (line[0] == 0x00) # e.g. 0x00 0x00 0x55 would be found
        ##        return
        ##else: # this is level 1 - waiting for 0x00 for next level
        ##    self.loop_state = (line[0] == 0x00)
        ##    if not(self.loop_state):
        ##        #if self.debug:
        ##       print(f"in < {line[0]:02x} not a proper sync -wait for sync-")
        ##        pass
        ##    return
        line = b'\x00'+ self.serial.read(1)
        while(not line[1]==0x55 ):
            if self.serial.any()==0:
                return
            line = b'\x00'+ self.serial.read(1)
            
        line += self.serial.read(1)
        #line = self.serial.read(2)

        #if(not len(line)==11 ):
        #    
        #    return

        raw_pid = line[2]
        if raw_pid in self.DISPLAY_STATUS_PIDS: print(f"status-message found with {raw_pid:x}")#0x20 0x61 0xe2 

[mc0110]

Hi @florent314, thanks for the quick reply. I won't find the time to test it with my PI pico for another 2 weeks. Maybe the others with the problem will test if it works for them. I'm sure we'll get the patch in GITHUB working and of course you can also adapt the instructions. Thanks a lot M.

[Deleny74]

Hi florent314, hi Magnus,

I've implemented the changes and it's working fine. The RP Pico is now connected with the CP+.

Thank you very much.

LG
Andreas

[mc0110]

Great news! So I'll commit the change and we will revise the code again later

[Tins612]

Thank you.
The Pico is now working on the LIN. What I did before it was running was to check its network IP address in Putty. Then I disconnected the laptop's USB port and connected a power supply to the Pico. Then, via the IP, I accessed the interface, where the credentials can also be entered. Then I ran the MQTT test command, switched to normal mode, and soft rebooted.

[mc0110]

Really good news!
So thanks for your answer and it is okay to close your issue