Bus Stop Request Buttons: How Passengers Signal the Driver

Updated July 2026

Every bus and coach needs a way for a passenger to say “I want the next stop” without shouting to the driver. That is the job of the stop request button: the round button on the grab rail, the seat-back or the door pillar that a rider presses, which lights a sign at the front and sounds a chime so the driver knows to pull in. It looks like the simplest control on the vehicle, and the button itself is simple. What turns it into an engineering decision is everything around it — how the press reaches the driver, how many buttons a long vehicle needs, and how the system serves a passenger who cannot see the overhead sign or hear the chime.

This guide is the version of the stop-request conversation we have with bus and coach OEM buyers during project scoping. It covers what the system is responsible for, how the signal moves from button to driver, the wired-versus-wireless decision, why accessibility changes the specification, and what to put in a request for quotation so a supplier can price it without a round of clarification emails.

1. What a stop request system actually does

On a small minibus a single button and a buzzer would do. On a full-size city bus or an articulated coach the same idea has to scale across a long saloon with standing passengers, and that is where it becomes a system rather than a switch. A modern stop-request installation is responsible for more than lighting a lamp.

• Registering a request from anywhere in the saloon. A passenger at the rear doors and a passenger by the front axle both need a button within reach, so a long vehicle carries many request points that all resolve to the same “stop requested” state.
• Confirming the press back to the passenger. The rider needs immediate feedback that the request registered — an indicator colour change, a chime, and on accessibility buttons a vibration — so they are not left pressing repeatedly.
• Telling the driver. A front annunciator chime and the illuminated “stop requested” sign put the request where the driver acts on it, and clear it once the doors open.
• Handling the accessibility case separately. A wheelchair or priority-stop request is treated differently from a routine stop — typically a longer dwell at the stop and a ramp-deploy prompt — so the system has to know which kind of press it received.
• Surviving the duty cycle. A door-area button on a busy route is pressed thousands of times a week, so the mechanism and the electronics are specified for a transit life, not a passenger-car one.

Most buyers treat the button as the whole product and the wiring as an afterthought. In practice it is the other way round: the button face is the simple part, and what decides whether a fleet is happy five years in is the reach coverage, the accessibility handling and the way the request is wired back to the vehicle. For where these buttons sit among the cabin switches and the rest of the input layer, the Switches and Sensors technical guide covers the full picture.

2. From button press to driver: the signal chain

Whatever the button looks like, the request travels the same path: a press is captured, a controller latches the request, and the controller drives the outputs the passenger and driver notice. Understanding that chain is what turns “we want stop buttons” into a specification a supplier can build.

The pieces work like this:

• The button captures the press. A self-return (momentary) action with a defined operating force — the JDK-2306 wired button uses a 12 ± 4 N press with more than 2 mm of travel — so the passenger gets a clear tactile click and the contact makes cleanly.
• The signal travels wired or wireless. A wired button closes a contact on a harness back to a controller input. A wireless button transmits a short 433.07 MHz burst that the EBX-2404 receiver picks up; that receiver carries a general channel and a separate accessibility channel, and learn-pairs up to 16 buttons.
• The controller latches the state. A body control module such as the EBX-954, or the receiver's own outputs, holds the “stop requested” state so a single quick press stays active until the stop is served. Keeping the latch in the controller, not the button, is what lets a dozen buttons share one request state without conflict.
• The outputs fire. The controller drives the front chime or voice announcement and the overhead sign, applies the accessibility response where the press came from an accessibility channel, and clears everything when the doors open.

3. Wired versus wireless

The first real decision is how the button connects, because that choice drives the harness, the mounting and the service plan far more than the button face does. Youlai builds both routes so the same passenger-request job can be solved either way, and the two share the same self-return feel and the same transit-grade sealing.

The honest way to choose is by the harness, not the button. Choose the wired JDK-2306 when the vehicle is designed from scratch with the button positions and the harness planned in, when you want buttons with no battery to change, or when you specifically want the vibration and braille feedback built into the button itself. Choose the wireless TDK-2406 / TDK-2407 when you are retrofitting an existing fleet, when the interior layout is not settled, or when running a harness down every stanchion is impractical — you trade a battery-service task for zero cabling. A common pitfall is treating this as an either/or decision for the whole vehicle. In practice many programmes mix both: wired buttons on the primary door pillars where the harness already runs, and wireless buttons to fill in the seat-back and mid-saloon positions that would otherwise need their own cable pull.

4. Accessibility and feedback types

Accessibility is the part of a stop-request specification that separates a transit-grade button from a generic push-button, and it is where public-transport buyers have the least room to cut corners. A passenger who cannot see the overhead sign or hear the chime over road noise still needs a reliable way to request the stop and to know the request registered. That drives two design decisions: what feedback the button gives, and how the system treats an accessibility press.

The feedback set works in layers, so a passenger gets confirmation through whichever channel is available to them:

• Visual. A clear indicator state change — the JDK-2306 sits green on standby and turns red the moment the press registers, at even brightness so it reads from a seated angle in daylight or at night.
• Audible. The front chime or a voice announcement confirms the request to the whole saloon and cues the driver.
• Tactile / haptic. A raised STOP legend and braille let a passenger locate and confirm the correct button by touch, and a short vibration pulse on press gives confirmation without needing sight or hearing — the combination that lets one button serve a sighted rider and a rider with low vision.

The second decision is system-level: an accessibility request is not the same event as a routine stop. A wheelchair user pressing the priority button usually needs a longer dwell at the stop and, on a low-floor vehicle, a ramp deployment. That only works if the system knows the press came from an accessibility button rather than a general one. On the wired side the accessibility button is wired to its own controller input; on the wireless side the TDK-2407 accessibility button pairs to a dedicated channel on the EBX-2404 receiver, separate from the general TDK-2406 channel. Either way the driver-side annunciator can respond to the two press types differently. Region-specific accessibility rules for public transport vary, and the exact dwell and ramp behaviour is defined by the vehicle programme rather than the button; what the hardware guarantees is that the two request types stay distinguishable end to end.

5. How to write a stop-request specification

A requirement a supplier can quote against, rather than guess at, covers five things. Leaving any of them implicit is what turns a quotation into a round of clarification emails.

1. Button count and positions. How many request points, where they mount (door pillars, stanchions, seat-backs), and which of them are accessibility positions. This sets the quantity and the general-versus-accessibility split.
2. Wired, wireless, or a mix. Driven by whether the vehicle is a new build with a planned harness or a retrofit, as in section 3. Say which positions are which so the receiver channel budget and the harness are both sized correctly.
3. Feedback set at the button. Indicator colour states, buzzer, vibration and braille — specify per position, because the accessibility positions usually need the full set while general positions may not.
4. Controller interface. Supply voltage (the JDK-2306 runs 9–36 V), how the buttons map to controller inputs or to receiver channels, and how the front chime and overhead sign are driven. If a body control module such as the EBX-954 owns that logic, name the input and output map up front.
5. Mounting format and environment. Panel-mount versus rail-mount and the rail diameter (the JDK-2306 offers a φ32 or φ35 rail clamp or a flat-panel fit), plus the working temperature and ingress target the interior demands.

From a sourcing perspective, the button-to-output map is the line buyers leave implicit and regret. The buttons and the receiver are the easy part; how a given press turns into a chime, a sign and an accessibility dwell is where integration time goes. Provide that map early and the system pairs against your vehicle plan instead of stalling in clarification.

6. What to look for in a supplier

A passenger-facing control that gets pressed thousands of times a week and carries an accessibility function stays on the vehicle for its whole life, so the supplier questions that matter are about capability and support, not headline price.

• Quality system in hand. Ask for the IATF 16949 certificate and what the PPAP package contains. Youlai manufactures under IATF 16949 with a PPAP package on programme handoff. Treat any verbal “automotive grade” claim without a certificate number as marketing.
• Both wired and wireless on one system. The most useful suppliers offer wired and wireless buttons that resolve to the same controller logic, so a mixed installation runs as one system. Confirm that the wired button and the wireless receiver share the same request semantics before committing to a fleet layout.
• Genuine accessibility feedback. Vibration and braille at the button, and a separate accessibility channel through the system, are the features that make the difference in a public-transport tender. Confirm they are built in, not a sticker over a standard button.
• Cycle-life and sealing evidence. A door-area button lives a hard life. Ask for the rated operations (200,000 for the wired button, 300,000 for the wireless) and the ingress and vibration validation, and confirm they come from testing rather than a datasheet copy.
• Region-specific radio approvals. Because the wireless button is a radio transmitter, market approvals such as CE / RED for Europe, FCC for North America and SASO for the GCC are available upon project requirement, not blanket-claimed across the catalogue. An honest supplier separates what it holds in hand from what it runs on a project basis.

Youlai validates in an in-house environmental laboratory with EMC pre-compliance equipment, and the contact page reaches the project team directly for a sourcing conversation.

Questions you will be asked at RFQ stage

• MOQ and samples. A standard wired button or a wireless button-and-receiver pairing can usually move to samples quickly; a custom legend, colour or channel scheme follows the programme timeline. Sample quantities are agreed per programme.
• Lead time. Driven mostly by how much is configuration versus custom development, and by any bespoke mounting or legend tooling.
• PPAP timeline. The IATF 16949 PPAP package (drawings, BOM, control plan, FMEA, dimensional and test reports) is prepared on programme handoff.
• Customisation scope. Legend and braille layout, indicator colours, the wireless channel mapping and the mounting format are routine configuration items, not exceptions.

7. Suggested next step

If you are scoping a stop-request system for a bus or coach programme, the most useful things to bring to a first conversation are the button count and positions with the accessibility split marked, whether each position is wired or wireless, the feedback set you need at the button, and how the chime and overhead sign are driven. That lets us pair the JDK-2306 wired button and the TDK-2406 / TDK-2407 wireless buttons with the EBX-2404 receiver against your vehicle plan, or tell you honestly where a custom configuration is needed. For how these buttons fit with the CAN switch panels and the rest of the cabin input layer, the Switches and Sensors technical guide covers the full stack.

For a button-to-controller wiring schedule, a pairing procedure for the wireless system, or a full saloon layout against your vehicle programme, please use the contact page or message +86 134 6767 4786 on WhatsApp. Typical reply within 24 hours during China business hours (UTC+8).