I have been messing a bit with my PetPorte to see if I could get it to talk. I have the REV-X6 version of the board which is not compatible with the custom firmware. I might be able to get it to work, but I am afraid that the upgrade might not be completely transparent to my cats

It took two months to get one of the cats to learn to use it. I don't want to give it any excuse to thinking that it is OK to meow until the door opens

I took a logic analyzer to the EUSART pins. There is no data being sent on the TX, and sending random data on RX does not provoke any response. The only action I see on these pins are that the JP5 pin5 (RC5 on the pic) is pulled low momentarily during at start up. Its around the same time as when the boot-up beep is heard. It is not an artifact of the beep itself as this does not happen on other beeps than the boot-up beep. There is some ripple on the lines, around 1Hz, probably syncronous with the RFID scans.
I have enabled and disabled all of the undocumented extended modes (8 through to 13) without any change of the behaviuor of these pins.
If there was a PC connection planned when the cat flap was released, they had to plan an upgrade by the customer. That means no soldering, no super-complicated button presses, no PCB replacement etc. I think they intended the extension to be autodetected. Possibly being activated by the extended modes. Autodetection would be prefered.
I think the RC5 low-blip is a signal for the extension board to start communication. My thinking is that the extension module should react to that signal, and send some bytes to identify itself, within a certain amount of milliseconds. After that, the main board will start to send data.
One way to test this would be to start sending random data to the RX pin as soon as the RC5 is pulled low. This might provoke some activity on the TX pin. It all depends on how picky the main board is on what data it expects. Is it just any old data, or is it a specific key, or a specific byte?
It might be possible to brute-force it. Use an adruino to reboot the board (cut power), start sending bytes att the low-signal, monitor for TX activity. If none, redo with next byte.
Best regards,
Simon