IoT Fire Alarm Device Design
Thought for 8 sec
You should ask Quectel / supplier for the EC25MXGA hardware design package, not just the marketing datasheet.
Ask for:
-
EC25MXGA Hardware Design Guide
- Full pin descriptions
- Power supply requirements
- PWRKEY / RESET timing
- UART / USB / SIM / RF reference circuits
- VDD_SDIO usage guidance
-
Recommended PCB land pattern / footprint
- Pad dimensions
- Pad numbering
- Paste mask / solder mask recommendations
- Keepout zones under/around the module
- Assembly notes
-
Reference schematic
- VBAT_RF / VBAT_BB decoupling
- SIM socket wiring
- Antenna matching / ESD
- Status pins
- Power-on/off sequence
-
RF layout guidelines
- 50 Ω antenna routing
- Ground stitching via recommendations
- Antenna connector/matching network placement
- Diversity/GNSS pins if used or unused
-
Certification documents
- RCM / ACMA / AS/CA S042 relevance
- Carrier approval info for Australia
- LTE band support for AU carriers
- Test reports if available
-
Lifecycle / supply confirmation
- Active production status
- Recommended replacement if EC25MXGA is not preferred
- Minimum order / lead time
Short message you can send:
We are designing a dual-modem Australian fire alarm signalling device using 2 × EC25MXGA. Please provide the EC25MXGA hardware design guide, recommended PCB land pattern/footprint, reference schematic, RF layout guide, SIM interface recommendations, VDD_SDIO connection guidance, Australian carrier/certification documentation, and lifecycle/supply status.
Ok I’ll contact them
Thought for 14 sec
Good plan. Ask them specifically for the hardware design guide + recommended PCB land pattern for EC25MXGA-128-SNNS.
Until we get that, the safest path is:
- Keep EC25MXGA in the design.
- Do not send the PCB to manufacture yet.
- Continue with placement/routing cleanup only as a draft.
- Finalize modem footprint, SIM wiring, RF layout, and
VDD_SDIOtreatment once Quectel confirms the official guidance.
Clean draft layout
Review EC25 wiring
Check power budget
Update factory checklist
Run current checks
Refine this doc
Ask about this doc
Sealed Resistor-Pack Input Architecture
User decision
The 8 inputs will accept field/FDCIE signals for Alarm, Fault, and Isolate. We do not need to exactly copy the older Centaur or RM3119 resistor board; we can design our own sealed resistor-pack interface as long as the ASE can reliably decode the required states.
Additional confirmed requirements:
- Dedicated power-fail input.
- 3 programmable relay outputs.
Recommended input architecture
Use 8 identical supervised input channels on the ASE board, each connected to a sealed external resistor-pack / EOL module installed at the FDCIE side.
Each sealed resistor pack should accept voltage-free FDCIE relay contacts for:
- Alarm
- Fault
- Isolate / Disabled
The sealed pack converts those contacts into a single supervised two-wire analog signal back to the ASE input.
States each input should decode
Each of the 8 supervised inputs should support these logical states:
- Short circuit / line fault
- Normal
- Isolate
- Fault
- Isolate + Fault
- Alarm
- Alarm + Isolate
- Alarm + Fault
- Alarm + Fault + Isolate
- Open circuit / line fault
This preserves the richer Centaur-style state decoding while allowing our own sealed resistor-pack implementation.
ASE-board hardware per input
Recommended per-channel circuit:
- Two-position terminal pair: INx+ / INx-.
- Surge/ESD protection suitable for fire-panel wiring.
- Current-limited excitation source or pull-up network.
- RC filtering for noise immunity.
- ADC measurement into STM32H757.
- Optional comparator/window-fault hardware if required for safety monitoring.
- Firmware debounce and threshold-band decoding.
Power-fail input
Provide a separate dedicated power-fail input for FDCIE power supply trouble/failure.
Recommended behavior:
- Accept voltage-free relay contact from the FDCIE power supply fault output.
- Supervise this input where practical, or support a resistor-pack option.
- Log and transmit as PWR / Power Fault.
- Treat it separately from the ASE’s own supply-voltage monitoring.
3 programmable relays
Provide 3 relay outputs controlled by firmware.
Recommended schematic features:
- Relay coils driven by protected low-side MOSFET/transistor drivers.
- Flyback suppression per relay coil.
- Contact terminal blocks clearly separated from logic.
- Contact ratings documented in installation/user documentation.
- Firmware-configurable functions, e.g. local fault, comms fail, alarm repeat, trouble, isolate active, service/test active.
- Relay state should fail to a defined safe state on MCU reset or power loss.
Schematic implication
The main board should include:
- 8 × supervised analog input channels.
- 1 × dedicated power-fail input channel.
- 3 × programmable relay outputs.
- Documentation fields for resistor-pack wiring, voltage bands, contact requirements, cable requirements, relay contact ratings, and commissioning tests.
Open decisions before final resistor-pack design
- Exact resistor values and voltage bands for the sealed pack.
- Whether each sealed pack supports Alarm/Fault/Isolate on every input, or only selected inputs need all three functions.
- Whether power-fail uses the same sealed-pack method or a simpler dedicated supervised contact input.
- Relay contact rating and default firmware functions.
User decision
Recommended input architecture
States each input should decode
ASE-board hardware per input
Power-fail input
3 programmable relays
Schematic implication
Open decisions before final resistor-pack design
