I've done some more OmniPro II reverse engineering after deciding to learn about the incredible power of the $5 RPi Pico2's programmable io (PIO) state machines. So I used PIO to implement bus capture of the communication between the OP2 cpu and dsp.
Why? I have a vague idea of implementing direct digital IP alarm reporting without analog dial-out DTMF generation/decoding (10-20 second delay) and third party middlemen (Alula, etc.) adding more delay and extra cost.
I've captured dsp bus reads/writes for a dial out report and see how it sends phone number digits (1 at a time, probably waits for status after each) then the Contact-ID message (first 4 digits, account number, also 1 at a time then next 12 digits consecutive writes). With this info I could implement a very clunky/crude IP communicator but it would need my analog central station emulator from
post #24 to fool the OP2.
Best result would be finding the firmware code that handles a dialout report, bypassing all of the phone related parts and just sending a simple digital message to an external mcu/ethernet board which handles all the IP alarm details.
I also updated the dsp info in
post #25.
Picture shows my wired up Pico2 "logic analyzer" which just has level translators that aren't even needed here because the dsp io is 3.3v.
EDIT: This may not be as impossible as it sounds. I've located all firmware code that communicates with the dsp and I've isolated 2 routines that send DTMF tones for phone number and contact-ID report. My bus capture trace has the dsp responses that indicate success so I have everything I need to bypass that code. To speed testing/debugging I may make an EPROM emulator out of one of my Pico2 boards (limit of 512KB so 3.x firmware?).