Command sending unreliable

[netmindz]

On my tub with ESP32 and ARCELI RS485 adapter, command sending is a bit hit and miss, so code currently retransmits until the FA changes in response to the command.

Some other users do not need to retry, but send 3 x IDLE messages between each real command

On my T-RSC3 board, even the command resending does not trigger a response. This is only a single-core MCU

[fherbert]

Just working through the code to send commands now and I've noticed that the variable used to store the command is declared as an array of 18 bytes, this is not correct, it's actually only a 9 byte array so you are sending 9 extra 0x00 bytes at the end of each command. You can see this on my logic probe trace below. Not sure if this is causing any problems - I have intermittent success sending commands, but it's not the correct length of a FB command.

[netmindz]

Ah well spotted!

As your better scope is able to show, I'm still sending data when the pin goes high, I'm outside of the time window

[netmindz]

I've applied the fix and it's looking like things are more reliable now. I need to connect up my laptop to see for sure and test if I can now remove the retry

[fherbert]

I'm wondering if we should be calculating the crc for each command - although in my testing it seems to work (mostly) when running commands that are 'hard coded'. For an experiment on dynamically creating commands I've created this bit of c-code here. Might be something to think about? I'm taking the liberty to assume what some of the bytes in the FB message represent.

[netmindz]

Are you able to check with your scope @fherbert the timings between the FA as FB of a real panel vs our current code? The delay of 40 at the moment is just a guess

[fherbert]

The top panel starts sending the FB message at an average of 240us from the end of the FA message.

[netmindz]

Thanks for that info. I wonder if we can get away with a fixed delay in the code or if I need to keep track of when the last byte of the FA was received vs when the code actually gets to the point of being ready to send

[netmindz]

Just pushed update that waits 500ms between trying to send any command, which seems to have helped multi-command actions be more reliable

[netmindz]

I've also rebuilt my setup from what had become a bit of jumble of connections with a "clean" setup of properly soldered connections rather than random wires shoved in what were the headers for the previous RS485 adapter. With the new hardware and correct message length I'm still not seeing 100% success so have kept the retry code in for now. Might have another go at removing but then sending the IDLE like I think you have tried @tmjo ?