SF32 BLE Talkback 인터컴¶

Talkback이란 무엇인가?¶

OpenSiFli Talkback은 Huangshan Pi로도 알려진 SF32LB52-DevKit-ULP용 멀티 디바이스 BLE 푸시투토크(PTT) 예제입니다. 디바이스는 룸을 만드는 Master로 동작하거나, 룸을 스캔하여 참가하는 Slave로 동작할 수 있습니다. 참가한 뒤에는 말하기 키를 누르고 있으면 송신하고, 떼면 송신을 멈춥니다. 공식 기준 구성은 최대 8대의 디바이스를 수용하며 최대 3대가 동시에 말할 수 있습니다.

이 프로젝트는 음성 인코딩에 Opus를 사용하고, RGB LED, 키, 디스플레이를 결합하여 최소한의 로컬 인터페이스를 구성합니다. 또한 한 번의 키 입력으로 Slave 재연결, 배터리 전압/잔량 보고, 입력 없이 60초가 지나면 슬립, 길게 눌러 전원 끄기 및 켜기 동작을 구현합니다. 따라서 독립된 일대일 오디오 예제보다 휴대용 인터컴 레퍼런스로서 훨씬 유용합니다.

왜 SF32 구현인가?¶

이 경로는 SF32LB52의 BLE, 오디오, 디스플레이, 키, 배터리 모니터링, 저전력 동작을 하나의 동작하는 기준 구성에 결합합니다. 팀은 커스텀 RF, 오디오, 전원 설계에 투자하기 전에 지원되는 개발 하드웨어에서 네트워킹과 오디오 성능을 평가할 수 있습니다.

"최대 8대의 디바이스와 3명의 동시 화자"는 업스트림 구현의 경계일 뿐, 거리, 간섭, 패킷 손실, 모든 동시 동작 패턴에 걸쳐 검증된 제품 기능이 아닙니다. 업스트림 자료에는 룸 인증, 링크 암호화 정책, 음성 프라이버시 보장, 무선 규제 상태, 바이너리 talk_back 컴포넌트의 전체 라이선스 경계도 명시되어 있지 않습니다. 이들은 각각 별도의 제품 검토가 필요합니다.

보드 출처 참고: SiFli의 중국어 ULP 보드 페이지에는 아직 제공되지 않는다고 명시되어 있으며, 저전력 센서/웨어러블 용도, 3축 또는 6축 센서 선택지, 예약된 저전력 테스트 포인트만 나와 있습니다. 완전한 보드 사양이 아닙니다. 주변 장치는 실제 보드 리비전과 회로도를 기준으로 확인하십시오. 아래의 Talkback 관련 동작은 고정된 애플리케이션 소스를 기준으로 합니다.

목표, 범위, 시작 조건¶

목표: 리비전이 관리되는 보드 두 대 이상으로 룸 생성, 참가, PTT 음성, 나가기/재연결, 슬립/웨이크, 배터리 상태 동작을 재현한 다음, 커스텀 하드웨어가 정당한지 판단하기에 충분한 증거를 보관합니다.

범위 밖: 이 페이지는 장거리 커버리지, 열화된 링크에서의 음성 품질, 종단 간 암호화, 인증, 양산 전력, 안테나 일관성, 규제 준수, 임의의 BLE 디바이스와의 호환성을 입증하지 않습니다.

시작 조건: 팀이 SiFli-SDK 빌드 환경을 설치하고, UART로 펌웨어를 기록하고, 로그를 확인하고, 스피커와 배터리를 안전하게 연결할 수 있어야 합니다. 완전한 음성 기준 구성에는 동일한 리비전의 보드가 두 대 이상 필요합니다.

하드웨어 및 소프트웨어 사양¶

하드웨어 사양¶

소프트웨어 사양¶

지원되는 기준 구성 선택¶

리비전이 같은 SF32LB52-DevKit-ULP 보드 두 대로 시작하십시오. 데모 저장소를 6fa55ac에 고정하고, ^2.4를 만족하는 구체적인 SiFli-SDK 커밋을 선택하여 기록하고, talk_back/1.2@sifli의 Conan 해석 결과를 보관하십시오. 첫 재현 단계에서는 오디오 파라미터, 역할 로직, 저전력 타이밍을 변경하지 마십시오.

저장소 루트에서 실제로 존재하는 경로로 이동합니다.

cd talkback/project
scons --board=sf32lb52-lchspi-ulp -j8

Windows에서 생성되는 플래싱 스크립트는 build_sf32lb52-lchspi-ulp_hcpu\uart_download.bat입니다. 이를 실행하고 프롬프트가 나오면 적절한 COM 포트를 입력하십시오. 모든 디바이스에 동일한 기준 구성 이미지를 사용하고 각 보드의 식별 정보와 이미지 해시를 기록하십시오.

기본 조작과 상태 표시¶

프로젝트 개발 단계와 의사결정 지점¶

시스템 아키텍처와 의존성¶

flowchart LR
    subgraph A["Master — SF32LB52-DevKit-ULP"]
        AM["마이크"] --> AC["Opus / 오디오 처리"]
        AK["KEY1 / KEY2"] --> AN["룸 및 PTT 상태 머신"]
        AN --> AL["RGB LED / 디스플레이"]
        AC <--> AN
    end
    subgraph B["Slave — SF32LB52-DevKit-ULP"]
        BN["BLE Talkback 네트워크 컴포넌트"] <--> BC["Opus / 오디오 처리"]
        BC --> BS["스피커"]
        BK["KEY1 / KEY2"] --> BN
        BN --> BL["RGB LED / 디스플레이"]
    end
    AN <--> |"BLE 룸 제어 및 음성"| BN
    AP["배터리 / USB 전원"] --> A
    BP["배터리 / USB 전원"] --> B

주요 장애 영역은 BLE 스캔/룸 생성, 룸 상태 동기화, 동시 화자 스케줄링, Opus/음향 경로, 키 이벤트, 배터리 부족 상태와 슬립, 전원 키 복구, 공개되지 않은 컴포넌트/라이선스 세부 사항입니다. 먼저 역할과 상태를 진단한 다음, 무선, 오디오, 로컬 전원 장애를 구별하십시오.

1단계 — 수정하지 않은 소스 기준 구성 확립¶

목표: 고정된 소스, SDK, 해석된 의존성이 반복 가능한 이미지를 만들어 낸다는 것을 입증합니다.

1. 애플리케이션과 구체적인 SDK 커밋을 고정하고 의존성 해석 출력을 보관하십시오.
2. 클린 디렉터리에서 sf32lb52-lchspi-ulp를 빌드하여 보드 두 대에 기록하십시오.
3. 각 디바이스가 빨간색 LED가 켜진 Slave로 시작하는지 확인한 다음 키, 디스플레이, 배터리, 스피커 경로를 점검하십시오.

보관할 증거: 전체 버전 매니페스트, 빌드/플래싱 로그, 펌웨어 해시, 두 보드의 리비전, 시작 기록.

게이트 1 종료 기준: 동일한 입력으로 동일한 기준 구성 이미지를 재현 가능하게 생성하여 두 디바이스에 기록하고, 시작 상태가 업스트림 동작과 일치합니다.

2단계 — 룸 설정과 양방향 PTT 검증¶

목표: 디버거 개입 없이 사용자가 최소 룸을 만들고 사용할 수 있음을 입증합니다.

1. Standby 상태에서 KEY2를 짧게 눌러 한 디바이스를 파란색 LED가 켜진 Master로 설정하고 다른 디바이스는 빨간색 Slave로 두십시오.
2. 두 디바이스에서 KEY2를 길게 누르십시오. Master는 룸을 생성하고 Slave는 스캔합니다. 페어링은 30초 후 타임아웃됩니다.
3. 대기 상태에서 Master의 KEY2를 길게 눌러 시작하십시오. 말하기 상태에서는 KEY2를 누르고 있으면 말하고, 떼면 중지합니다.
4. 송신 중에는 녹색, 수신 중에는 주황색으로 표시되는지 확인하고 양방향 음성이 알아들을 수 있는지 점검하십시오.

보관할 증거: 역할, 조작 타임라인, LED 상태, UART 로그, 양방향 오디오 샘플, 재시도 결과.

게이트 2 종료 기준: 디바이스 두 대 이상이 양방향 PTT 세션을 반복해서 완료하고, 표시등이 실제 오디오 방향과 일치하며, 30초 타임아웃 후 설명 가능한 상태로 돌아갑니다.

3단계 — 나가기, 재연결, 수용 한계 검증¶

목표: 업스트림의 복구 경로와 수용 한계로 인해 사용자가 막다른 상태에 빠지지 않음을 확인합니다.

1. 말하기 상태에서 나가려면 KEY2를 뗀 뒤 KEY1을 짧게 누르십시오. 송신 중에는 디바이스가 나갈 수 없습니다.
2. 이전에 참가에 성공한 Slave는 Standby 상태에서 KEY1을 짧게 눌러 재연결하십시오. Master에는 이에 해당하는 재연결 경로가 없습니다.
3. 통신 범위를 벗어난 상황, 페어링 타임아웃, Master 연결 끊김, 전원 재시작을 재현하십시오.
4. 다자간 동작이 중요하다면 의도한 참가자 수까지 늘리고, 명시된 한계인 디바이스 8대와 동시 화자 3명을 포함해 검증하십시오.

보관할 증거: 모든 장애에 대한 초기 상태, 트리거, 복구 동작, 복구 시간, 로그, 최종 룸 멤버십.

게이트 3 종료 기준: 대상 장애마다 명시적이고 반복 가능하며 사용자가 이해할 수 있는 복구 경로가 있고, 필요한 수용 한계와 동시 동작 한계를 한계 설명에서 가져오지 않고 대상 RF 환경에서 측정했습니다.

4단계 — 오디오, RF, 전력 성능 평가¶

목표: 개발 보드의 동작이 의도한 인클로저, 통신 거리, 동작 시간을 뒷받침할 수 있는지 판단합니다.

1. 조용한 환경, 근단 더블토크, 배경 소음, 여러 스피커 볼륨 설정에서 명료도, 클리핑, 에코, PTT 시작/종료 시 잘림을 기록하십시오.
2. 대상 거리, 장애물 통과, 2.4 GHz 간섭 환경에서 연결, 끊김, 복구를 기록하십시오.
3. 입력 없이 60초가 지나면 슬립에 들어가는지, 역할이 Slave로 리셋되는지, 아무 키로 웨이크되는지, 길게 눌러 전원을 끄고 켤 수 있는지, 배터리 20% 미만에서 LED 표시가 나타나는지 검증하십시오.
4. Standby, 송신, 수신, 슬립, 웨이크 전류를 측정하십시오. 개발 보드의 측정값을 최종 제품의 배터리 수명과 동일시하지 마십시오.

보관할 증거: 환경, 보드/안테나 방향, 오디오 파일, 거리와 간섭, 전류 트레이스, 배터리 조건, 복구 결과.

게이트 4 종료 기준: 제품 팀이 대상 환경에 대한 음향, RF, 전력, 웨이크 임계값을 정의하고 충족했으며, 충족하지 못한 항목마다 담당자와 처리 방안이 있습니다.

5단계 — 제품 준비 상태 검토¶

커스텀 하드웨어로 넘어가기 전에 최소한 다음 질문에 답하십시오.

• 룸이 신뢰할 수 있는 디바이스를 어떻게 식별하며, 음성 및 제어 데이터에 어떤 인증, 암호화, 재전송 방지가 적용되는가?
• talk_back/1.2@sifli, Opus, WebRTC 컴포넌트, 저장소 소스 파일의 라이선스, 소스 제공, 취약점 대응은 누가 책임지는가?
• 대상 안테나, 인클로저, 인체에 의한 차폐, 동시 동작 조건에서 커버리지, 지연 시간, 패킷 손실, 복구를 어떻게 측정했는가?
• 마이크, 앰프, 스피커 캐비티, 볼륨 제한이 음향 및 안전 요구 사항을 어떻게 충족하는가?
• 디바이스는 배터리 부족, 비정상적인 전원 손실, 손상된 펌웨어, 실패한 현장 업데이트에서 어떻게 복구하는가?
• Bluetooth, EMC, 무선, 배터리 적합성 관련 활동 중 어느 것이 적용되는가?

게이트 5 종료 기준: 리스크 대장에 증거, 담당자, 완화책, 명시적인 진행, 보류 또는 중단 결정이 있습니다. 보안, 라이선스, 규제 문제를 담당자 없는 "나중에" 할 일로 남겨 두면 안 됩니다.

제품 설계로의 인계¶

인계 패키지에는 고정된 소스/SDK/의존성, 역할과 상태 머신, 수용 한계 및 복구 매트릭스, 오디오/RF/전력 측정, 안테나와 음향 가정, 배터리/충전 경계, 보안/프라이버시 모델, 라이선스 자료, 양산 테스트 요구 사항, 복구 계획이 포함되어야 합니다. SF32LB52x 통합 경로를 사용하여 칩, 모듈, 보드, 하드웨어 설계 가이드, 체크리스트를 선택하십시오. 검증된 동작을 커스텀 회로도와 레이아웃에 반영하고, 개발 보드의 결과가 그대로 이어진다고 가정하지 말고 다시 확인하십시오.

주요 정보 출처¶

• OpenSiFli Talkback 디렉터리
• 애플리케이션 검토 커밋 6fa55ac
• 공식 Talkback README
• Talkback Conan 매니페스트
• Talkback 프로젝트 구성
• OpenSiFli/SiFli-SDK
• 공식 SF32LB52-DevKit-ULP Wiki 소스
• 중국어 SF32LB52-DevKit-ULP Wiki 소스

최종 업데이트: 2026-10-19