HAI Omni engineer/developer thread

I've been busy with other projects but did finally trace out the phone circuit on my OmniPro II (schematic attached). There's not much in the audio path to go wrong. Besides a bad capacitor or leaky transistor/protection-device, the only thing is audio codec U3.
I have a board I bought way back on ebay as a backup but never tested. Cant see phone line, been trying to draw out the chema for that section for a while. Thanks!
 
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?).
 

Attachments

  • pico2-capture.jpg
    pico2-capture.jpg
    126.2 KB · Views: 8
Last edited:
Here's a schematic of the EPROM jumpers described in post #16. The flash chip is completely disabled by removing the jumper, perfect if you want to use the EPROM socket for an emulator or a chip with different firmware. HAI likely used this for initial/recovery programming of the firmware flash.

EDIT: I've confirmed this on a 4.0b firmware flash board by removing the JP10 jumper and installing a 3.0 chip eprom. The panel started up after a short delay and showed 3.0 firmware. It erased the installer code and other things (DCM phone number, etc.) in the CPU internal eeprom but other setup info seems to be there. Removed the eprom chip and put back JP10 jumper and panel starts up with 4.0b firmware. We now have a easy way to reset installer code on a flash board!
 

Attachments

  • HAI-OmniProII-EPROM-Jumpers.png
    HAI-OmniProII-EPROM-Jumpers.png
    40 KB · Views: 4
Last edited:
Back
Top