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
Processor + Dual Quectel Hardware Baseline
Confirmed hardware baseline from user
- 8 supervised inputs
- 3 relay outputs
- 2 × Quectel cellular modules
- 1 × STM32H757-class processor / MCU (
STSM757H3as written by user; exact part number to confirm; recommended STM32H757ZIT6/STM32H757ZI family) - 2 × external cellular antenna ports
- Antenna connection method: PCB u.FL/IPEX-style connectors with pigtails to external panel antenna connectors
- 2 × SIM slots
- Modem operation: hot redundant; both modems/SIMs always active
- Server polling/check-in: every 20 seconds from both modem paths
- Front screen: SPI LCD-style display
- Front buttons: 4 navigation buttons — Up, Down, Left, Right
- Isolate key: Dallas/iButton-style key
- USB-C used for programming/service
- Input power: 12–24 VDC nominal
- Incoming power protection: reverse-polarity protection, incorrect-voltage protection, surge/ESD/transient protection, brownout detection, and power-usage monitoring
Architecture direction
- The STM32H757 is the main controller for input supervision, relay control, LCD/buttons, Dallas/iButton isolate state, event logging, modem supervision, and communications failover.
- Each Quectel module should have independent power control, reset/PWRKEY control, SIM interface, external RF connector, status monitoring, and serial/control interface to the STM32.
- Each modem needs an independently protected high-current rail because EC21-class modules can draw up to about 2 A transmit peaks.
- Each external antenna path uses a PCB RF connector to pigtail, RF ESD protection, 50 Ω controlled-impedance routing, RF keepout, and careful grounding.
- The 3 relays should be treated as safety-relevant outputs and include contact rating, flyback/coil drive protection, and firmware state supervision.
- USB-C should be kept as programming/service only unless later changed; do not make it the certified main power path by default.
Power architecture baseline
- 12–24 VDC input terminal.
- Fuse/eFuse at the input.
- Reverse-polarity protection; ideal-diode/MOSFET preferred over simple series diode for lower heat and voltage drop.
- TVS diode and EMI filtering for field-supply transients.
- Over-voltage cutoff for incorrect input voltage; initial target is to survive around 29 V continuous and disconnect above approximately 30–33 V, to be finalized.
- Brownout/under-voltage detection and firmware logging.
- Two independent 4.0 V, ~3 A modem buck rails: MODEM_A and MODEM_B.
- 3.3 V system rail for STM32 and logic, sized around 1.5–2 A initial target.
- Separate LCD backlight rail if required by display.
- Per-rail power-good/fault signals to STM32.
HMI / service interface
- LCD screen displays system status, alarm/fault/isolate state, modem/SIM path status, signal/service state, power status, and event/service menus.
- Four front buttons provide menu navigation: Up, Down, Left, Right.
- Dallas/iButton-style key input provides authorized ASE isolate mode control and must be supervised/logged in firmware.
- USB-C provides programming/service/debug access.
Decisions still needed before schematic
- Confirm exact orderable MCU part number/package.
- Confirm relay contact rating and function of each relay.
- Confirm Quectel exact part number and whether EC21-AUV remains mandatory.
- Confirm STM32-to-Quectel interface: recommended UART per modem plus PWRKEY/RESET/STATUS GPIO.
- Confirm final external panel connector type: SMA is the current default via pigtail.
- Confirm LCD electrical module/backlight requirements.
- Confirm final reverse-polarity topology: simple diode, bridge, or low-loss ideal diode/MOSFET.
- Confirm over-voltage cutoff threshold and required surge standard/test level.
Confirmed hardware baseline from user
Architecture direction
Power architecture baseline
HMI / service interface
Decisions still needed before schematic
