RoomRadar Guides

LanguageEnglishSvenska
Go to Dashboard

Device reconnection behavior

Know what normal reconnect behavior looks like, how to recover in under a minute, and when reconnect patterns signal deeper reliability issues.

Updated: 6 March 2026Difficulty: Advanced
advancedreconnectreliabilitytroubleshootingtranscripts

This guide helps you distinguish normal reconnection from real stability issues. Use it when a table phone drops and reconnects and you need to know how transcript and summary quality are affected.

Quick path:

  1. Confirm whether one table or many tables are affected.
  2. Keep the table talking while you reconnect.
  3. Check that new text returns to the correct group within about a minute.
  4. Reconfirm the latest decision verbally.

What normal reconnection looks like

A normal drop is short: the phone disconnects, reconnects, and text flow returns with a small delay. You may see a minor transcript gap, but the session continues in the same group.

That is different from prolonged instability. If flow returns and the table can restate the latest point, the situation is usually under control.

One-minute live routine

  1. Tell the table: "Please continue, we are restoring connection now."
  2. Reconnect the phone to the same group.
  3. Confirm microphone permission is still enabled.
  4. Check that transcript lines start flowing again.
  5. Ask for a one-sentence restatement of the latest decision.

If reconnection does not stabilize quickly, switch to [Replacing a phone mid-session](/guides/setup/replacing-a-phone-mid-session).

When reconnection becomes a pattern

If the same table drops repeatedly in a short window, treat it as a stability issue:

  • check local network quality
  • reduce movement across network zones
  • keep the phone in a stable position

If several tables drop at once, run [Workshop infrastructure reliability checklist](/guides/advanced/workshop-infrastructure-reliability-checklist). If text delay appears at the same time, add [Troubleshooting transcription latency](/guides/advanced/troubleshooting-transcription-latency).

What to log for post-session analysis

Capture three fields per event: timestamp, table, and action taken. Add whether reconnection solved it or required replacement. This lightweight log makes repeat patterns much easier to diagnose later.

  • [Reconnecting a disconnected device](/guides/setup/reconnecting-a-disconnected-device)
  • [Replacing a phone mid-session](/guides/setup/replacing-a-phone-mid-session)
  • [Troubleshooting transcription latency](/guides/advanced/troubleshooting-transcription-latency)
  • [Workshop infrastructure reliability checklist](/guides/advanced/workshop-infrastructure-reliability-checklist)
  • [Microphone replacement without data loss](/guides/advanced/microphone-replacement-without-data-loss)

Related guides

Why transcript ordering matters

Protect interpretation accuracy by understanding where ordering drift appears and how to validate sequence-sensitive decisions.