Målgruppe:[fiks: engelsk-rest] Denne artikkelen er skrevet for maskinvareinnkjøpere og lyd‑firmware‑ingeniører som vurderer en lesepenn-serie for støyende klasserom og hjemmemiljøer. Den forutsetter at du allerede forstår sameksistens mellom Bluetooth og Wi‑Fi på et overordnet nivå, og at du nå trenger en forsvarlig spesifikasjon for PLC‑atferd ved pakketap.
Lydpakker er ikke det samme som lydrammer. En lesepenn-dekoder henter PCM-rammer ut av en komprimert bitstrøm, men transportlaget leverer disse rammene inne i pakker som kan gå tapt, omorganiseres, dupliseres eller bli forsinket. Når en pakke forsvinner – noe som skjer med noen få minutters mellomrom på alle produksjonslesepenner ved normal sameksistens mellom BLE og Wi-Fi – har dekoderen noen hundre mikrosekunder på å finne opp en erstatning før neste forventede sample ankommer. Denne erstatningsprosessen kalles Packet Loss Concealment (PLC), og kvaliteten på erstatningen avgjør om barnet hører et rent ord eller en glitch som får det til å trykke på OID-koden igjen. Denne artikkelen forklarer hvordan PLC er implementert på tvers av de 11 produksjonsmodellene (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6), hvordan det måles, og hvordan du spesifiserer PLC-robusthet i RFQ-en din, slik at du slipper å feilsøke det under et skoledistrikt-pilotprosjekt.
1. Hvorfor PLC er viktig i en lesepenn, ikke bare i VoIP
PLC ble oppfunnet for tale over IP, der den typiske pakketapraten på et administrert nettverk er 0,5–2 prosent og lytteren er en voksen som mentalt kan fylle inn en utelatt fonem. En lesepenn har en langt tøffere transportvirkelighet. Pennen sitter i et 2,4 GHz Wi-Fi-klasserom med 30 andre elever som strømmer video; pennen er også paret via BLE 5.0 til en foreldreapp; pennen kan samtidig kjøre sin egen Wi-Fi-skanning for å sende brukstelemetri til skyen. Pakketapprofilen på den lokale lydstien er ikke 0,5–2 prosent – den er klumpvis, med sporadiske 30–80 ms hull når Wi-Fi-radioen dominerer antennen og BLE-linklaget sender om sendingen.
VoIP-PLC-algoritmer ble designet for stasjonært, veloppdragent tap. PLC i en lesepenn må håndvere klumpvis tap, jitter-pigger og det sporadiske 200 ms-hullet når radiosystemet kjører en bakgrunnsskanning. Dekoderens oppgave er å finne opp en troverdig lydramme for hver manglende tidsluke, og deretter sømløst gi kontrollen tilbake til den virkelige bitstrømmen når pakkene kommer tilbake. En dårlig PLC-implementasjon klikker, smeller, eller – i verste fall – gjentar en stavelse, slik at barnet hører det samme ordet to ganger og blir forvirret.
På tvers av våre 47 000+ leverte enheter siden 2023, brytes lydrelaterte supporthenvendelser ned som følger: 38 prosent er PLC-artefakter (klikk, smell, gjentatte stavelser), 24 prosent er volum- eller AGC-problemer, 18 prosent er kodek-mismatch-feil, 12 prosent er høyttalermaskinvaredefekter, og 8 prosent er innholdsproduksjonsproblemer. PLC er det desidert største lydkvalitetsproblemet vi fikser i firmware, og plattformene L5, T2 og Y6 har spesielt investert ingeniørarbeid i PLC for å løse det.
2. Hvordan PLC fungerer i praksis
PLC-algoritmer faller inn i tre familier. Bølgeform-substitusjon er den enkleste: når en ramme mangler, gjentar dekoderen siste gode ramme med en fade-out. Dette fungerer for ustemte konsonanter og stasjonære vokaler, men høres robotaktig ut og gir hørbare diskontinuiteter på transienter. Pitch-synkron overlap-add (PSOLA) er mer sofistikert: dekoderen estimerer pitch-perioden til forrige ramme og syntetiserer en erstatning ved hjelp av denne perioden. Dette fungerer svært godt for ren tale og er det Opus bruker som standard. Modellbasert PLC bruker et lite nevralt nettverk eller signalmodell for å generere den manglende rammen; de nyeste RNNoise- og WaveNet-lignende PLC-implementasjonene hører hjemme her.
Lesepenn-porteføljen bruker to av disse familiene. På plattformene B1, B2, F8, K7, KF1, P2, Q6 og Q8 er dekoderen en fastfunksjons maskinvareblokk eller et portert Helix/MP3/AAC-bibliotek i fixed-point; PLC er implementert som en bølgeform-substitusjonsalgoritme med PSOLA-forbedringer lagt til i firmware 2.4.7 (B1/B2), 3.1.2 (F8), 1.9.5 (K7/KF1), 2.0.3 (P2) og 3.3.1 (Q6/Q8). På plattformene L5, T2 og Y6 er dekoderen libopus-referanseimplementasjonen som kjører på Cortex-A53, med PLC aktivert som standard på SILK+CELT-laget; dette er en modellbasert PLC som er dramatisk bedre ved klumpvis tap enn den eldre bølgeform-tilnærmingen.
For B2B-spesifikasjonsformål er den meningsfulle distinksjonen mellom fast PLC (en kjent algoritme leverandøren kan navngi) og adaptiv PLC (en algoritme som justerer sin skjulingsstrategi basert på observerte pakketapstatistikker). Alle 11 produksjonsmodeller bruker adaptiv PLC, men L5/T2/Y6-familien tilpasser seg raskere fordi Opus sin PLC er bygget inn i selve bitstrømmen.
3. PLC-implementasjon per modell
Tabellen nedenfor er det tekniske grunnlaget for de 11 produksjonsmodellene. «PLC-algoritme» navngir den spesifikke skjulingsstrategien i firmwaren; «PLC-konvergenstid» er hvor mange påfølgende gode rammer dekoderen trenger før den slutter å interpolere og begynner å stole på bitstrømmen igjen; «testet tapsprofil» er pakketapsmønsteret vi bruker i QA-godkjenning.
| Modell | Kodek | PLC-algoritme | PLC-konvergenstid | Testet tapsprofil | Firmware |
|---|---|---|---|---|---|
| B1 | AAC-LC | Bølgeform-substitusjon + PSOLA | 12 rammer | 5 % tilfeldig, 30 ms klumper | 2.4.7 |
| B2 | AAC-LC | Bølgeform-substitusjon + PSOLA | 12 rammer | 5 % tilfeldig, 30 ms klumper | 2.4.7 |
| F8 | MP3 | Bølgeform-substitusjon | 16 rammer | 5 % tilfeldig, 30 ms klumper | 3.1.2 |
| K7 | AAC-LC | Bølgeform-substitusjon + PSOLA | 10 rammer | 5 % tilfeldig, 40 ms klumper | 1.9.5 |
| KF1 | AAC-LC | Bølgeform-substitusjon + PSOLA | 10 rammer | 5 % tilfeldig, 40 ms klumper | 1.9.5 |
| L5 | Opus | SILK+CELT-modell PLC | 4 rammer | 5 % tilfeldig, 80 ms-burster | 4.2.0 |
| P2 | MP3 | Bølgeform-substitusjon | 16 rammer | 5 % tilfeldig, 30 ms-burster | 2.0.3 |
| Q6 | AAC-LC | Bølgeform-substitusjon + PSOLA | 8 rammer | 5 % tilfeldig, 40 ms-burster | 3.3.1 |
| Q8 | AAC-LC | Bølgeform-substitusjon + PSOLA | 8 rammer | 5 % tilfeldig, 40 ms-burster | 3.3.1 |
| T2 | Opus | SILK+CELT-modell PLC | 4 rammer | 5 % tilfeldig, 80 ms-burster | 2.6.4 |
| Y6 | Opus | SILK+CELT-modell PLC | 4 rammer | 5 % tilfeldig, 80 ms-burster | 2.6.4 |
Konvergensverdien fortjener oppmerksomhet. B1 og B2 trenger 12 gode rammer (~250 ms ved 22,05 kHz) før dekoderen igjen er fullt pålitelig etter et tap. L5, T2, Y6 trenger bare 4 rammer (~80 ms). I et faktisk klasserom mister pennen 30–80 ms lyd på grunn av en Wi-Fi-koeksistens-hendelse, og har deretter 250–800 ms ren lyd før neste hendelse. De eldre plattformene bruker omtrent en tredel av det rene vinduet på gjenoppretting; de nyere plattformene bruker omtrent en tidel. Subjektivt er dette forskjellen mellom «pennen klikker av og til» og «pennen klikker aldri».
4. De tre tapsmønstrene som faktisk inntreffer
PLC-litteraturen antar vanligvis ensartet tilfeldig pakketap ved én enkelt prosentandel. Det er ikke det som skjer i en lesepenn. I vår felttelemetri på tvers av 47 000+ enheter dominerer tre tapsmønstre, og hvert av dem krever en annen PLC-respons.
Mønster A – Wi-Fi-koeksistens-burst. Når pennens Wi-Fi-radio gjør en bakgrunnsskanning eller sender telemetri, legger BLE-linklaget lydpakker i kø i 20–80 ms og tømmer deretter køen. Lyden opplever et gap på 20–80 ms etterfulgt av en burst på 3–5 rammer. PLC må skjule gapet og ri gjennom bursten uten å klikke. Opus-PLC på L5/T2/Y6 håndterer dette sømløst; bølgeform-substitusjons-PLC på B1/B2/F8/P2 produserer et hørbart klikk i omtrent 30 prosent av tilfellene ved 60 ms-gap.
Mønster B – Utsortering ved overbelastning. Når BLE-linken sender pakker på nytt, kan pakker komme frem i feil rekkefølge. Dekoderen må avgjøre om den skal vente på pakken i riktig rekkefølge (introdusere jitter) eller spille den sene pakken etter en ekte (introdusere en feil). Opus' PLC beholder den sene pakken og bruker den til å forbedre kamuflasjen. Den fastfunksjonsbaserte AAC- og MP3-PLC-en på de eldre plattformene dropper den sene pakken fullstendig, noe som er riktig, men som betyr at den sene pakkens bidrag til modellen går til spille.
Mønster C – Langt fall ved lav RSSI. Når pennen er i utkanten av BLE-rekkevidden fra en paret foreldretelefon, kan lydpakker gå tapt i 200–500 ms sammenhengende. Dette er sjeldent, men det er feilmodusen som gir de verste feltrapportene. Opus-PLC på L5/T2/Y6 spiller forståelig, men stadig mer syntetisert tale de første 200 ms, og demper deretter høyttaleren for å unngå robotaktige artefakter. Bølgeform-substitusjons-PLC på de eldre plattformene gjentar den siste rammen og produserer en tydelig hørbar sløyfe.
5. Måling av PLC-kvalitet: PESQ og PLCQA
To objektive målinger er nyttige for spesifikasjon. PESQ (Perceptual Evaluation of Speech Quality) er ITU-T P.862-standarden og gir en poengsum fra 1,0 til 4,5. PLCQA er en nyere måling fra Audio Engineering Society, spesielt utviklet for PLC-evaluering, med poengsum fra 0 til 100. Vi måler begge på de 11 produksjonsmodellene ved hjelp av et standardisert 30-sekunders taleklipp med tre innsprøytede tapsmønstre: 5 % ensartet tilfeldig, 30 ms-burst ved 200 ms-intervaller og 60 ms-burst ved 500 ms-intervaller.
| Modell | PESQ @ 5 % tilfeldig | PESQ @ 30 ms-burst | PESQ @ 60 ms-burst | PLCQA-burst |
|---|---|---|---|---|
| B1 | 3.42 | 3.18 | 2.74 | 58 |
| B2 | 3.45 | 3.21 | 2.78 | 60 |
| F8 | 3.38 | 3.05 | 2.62 | 55 |
| K7 | 3.58 | 3.34 | 2.91 | 64 |
| KF1 | 3.58 | 3.34 | 2.91 | 64 |
| L5 | 3.92 | 3.81 | 3.62 | 84 |
| P2 | 3.35 | 3.02 | 2.58 | 53 |
| Q6 | 3.62 | 3.41 | 3.02 | 68 |
| Q8 | 3.62 | 3.41 | 3.02 | 68 |
| T2 | 3.90 | 3.78 | 3.58 | 82 |
| Y6 | 3.92 | 3.81 | 3.62 | 84 |
Forskjellen mellom de eldre plattformene med faste funksjoner og Opus-plattformene øker etter hvert som tapsmønsteret blir verre. Ved 5 prosent tilfeldig tap er spredningen 0,57 PESQ (3,35 til 3,92). Ved 60 ms burst-tap er spredningen 1,04 PESQ (2,58 til 3,62). Implikasjonen: hvis lesepenn-programmet ditt skal kjøre i et ekte klasserom med ekte Wi-Fi og ekte BLE, leverer L5/T2/Y6-plattformen merkbart renere lyd under stress enn B1/B2/F8/P2-plattformene.
For en innkjøper som skriver en RFQ, er terskelen vi anbefaler PESQ ≥ 3,5 ved 30 ms burst-tap og PLCQA ≥ 70 ved burst-tap. Hver plattform unntatt B1, B2, F8 og P2 klarer denne grensen i vår nåværende fastvare.
6. FEC, redundans og hvorfor vi ikke bruker dem som standard
PLC er en skjulealgoritme – den «finner opp» den manglende lyden i ettertid. FEC (Forward Error Correction) og pakkeredundans er forebyggingsalgoritmer – de sender lyden flere ganger slik at mottakeren kan rekonstruere originalen selv om én kopi tapes. Begge tilnærmingene finnes for VoIP, og begge er tilgjengelige på lesepenn-plattformene. Vi aktiverer dem ikke som standard av tre grunner.
[fiks: engelsk-rest] For det første dobler FEC og redundans omtrent lydbåndbredden over BLE‑linken. På en lesepenn med en 64 kbps lydstrøm legger FEC til ytterligere 16–32 kbps, som konkurrerer med lenkens budsjettreserve for OID‑oppslag-kvitteringer og BLE‑parringstrafikk. For det andre har kodekens PLC blitt god nok til at FEC gir mindre enn 0,2 PESQ-poeng på Opus-plattformene, noe som ligger under høreterskelen. For det tredje legger FEC til latens, og lesepenn-lyd er en «klikk-og-lytt»-opplevelse der enhver ekstra latens er en tilbakegang.
For OEM-er som bygger en lesepenn-linje for satelitttilkoblede klasserom (et nisje-, men reelt ønske fra MENA-distributører), aktiverer vi Opus sin innebygde FEC på L5 og T2. Flagget eksponeres i fastvaremanifestet ved fastvare-ID OPUS_INBAND_FEC=1 og legger til omtrent 4 kbps til bithastigheten samtidig som robustheten forbedres dramatisk, på bekostning av 20 ms ventetid.
7. PLC i felten: et skolepilotprosjekt med 12 000 enheter
Et pilotprosjekt i 2025 med en skolekrets i en gulfstat, fordelt på 47 skoler og rundt 12 000 lesepenner (en blanding av K7, KF1 og L5), genererte felttelemetrien som drev vår nåværende PLC-kjøreplan. K7/KF1-kohorten hadde en 4,2 prosent lydbillett-rate – definert som enhver supportkontakt som nevnte «klikking», «hopping», «gjentakelse» eller «merkelig lyd». L5-kohorten hadde en 1,1 prosent lydbillett-rate i samme miljø. Begge er under 5-prosentsterskelen som vår supportkontrakt behandler som akseptabel, men forskjellen er nøyaktig det man ville forutsi fra PESQ-tabellen.
Pilotprosjektet avdekket også en ikke åpenbar PLC-feilmodus: når et barn holder pennen svært nær et nettbrett som kjører en videoapp, er 2,4 GHz-interferensen fra nettbrettets Wi-Fi-bursts så sterk at pennen mister 100–200 ms lyd med noen sekunders mellomrom. Opus-PLC-en på L5 håndterer dette ved å gå over til en «muting»-modus etter 200 ms sammenhengende tap, som høres mye bedre ut enn B2s bølgeformsløyfe. Vi la til denne muting-modusen i K7- og KF1-firmware i versjon 1.9.5 og så at andelen lydbilletter sank fra 4,2 prosent til 2,6 prosent.
8. Slik spesifiserer du PLC i en innkjøpskontrakt
[fiks: engelsk-rest] En forsvarlig PLC-spesifikasjon har tre deler. For det første: angi algoritmen og kodeken: «Opus SILK+CELT PLC ved 48 kbps mono 24 kHz, ABR aktivert, innbånd FEC deaktivert.» For det andre: angi testmetodikken: «PESQ ≥ 3,5 under 30 ms bursttap med 5 prosent tilfeldig bakgrunn, målt med ITU‑T P.862 referanseimplementasjon.» For det tredje: angi felt-telemetrikkforpliktelsen: «leverandøren må rapportere lydbillett-rate per firmware-versjon, mål ≤ 2 prosent over et rullende 90-dagers vindu.»
Tre detaljer er viktige. For det første, testsignalet må spesifiseres — vi bruker ITU-T P.501-referansetalesekvensen normalisert til −26 dBov; leverandører som tester med sitt eget signal vil rapportere bedre tall. For det andre, tapsprofilen må spesifiseres — uniform tilfeldig på 5 prosent er et minimum; en 30 ms burstprofil er det som fanger den reelle feilmodusen. For det tredje, PESQ må måles på produksjonsfirmware, ikke på kodekens referanse — produksjonsdekoderen inkluderer feilskjuling, AGC og støydemping som kan flytte PESQ med 0,4 i begge retninger.
Tips til innkjøper: Be om PESQ-rapporten fra leverandørens nyeste firmwareversjon. Hvis leverandøren ikke kan levere en innen 24 timer, bør du behandle det som et gult flagg: PLC-måling er en del av standard release-QA på hver modell i vår portefølje.
9. PLC og OTA-oppdateringsmekanismen
En ofte oversett samhandling: PLC-atferden under en OTA-firmwareoppdatering er forskjellig fra PLC-atferden under vanlig avspilling. Mens OTA pågår, omskrives lydpartisjonen, og dekoderen kan stoppe i 200–800 ms mens en flash-sektor slettes. PLC-en må skjule denne pausen uten å lage et klikk og uten å miste synkroniseringen med bitstrømmen når den nye firmwaren tar over.
L5-, T2- og Y6-firmware 2.6.4 og 4.2.0 implementerer en spesiell «OTA mute»-modus som fader lyden til stillhet før sektorslettingen og fader den tilbake etterpå. K7- og KF1-firmware 1.9.5 gjør det samme. Den eldre B1-, B2-, F8- og P2-firmware gjør det ikke — lyden vil klikke under en OTA, noe som er akseptabelt fordi OTA på disse plattformene er en foreldredrevet handling som brukeren forventer avbryter avspillingen.
For en importør som selger til skoledistrikt som kjører OTA-oppdateringer over natten, er dette et reelt spesifikasjonspunkt: krev at firmwaren implementerer en OTA mute-and-resume-modus, og at mute-varigheten loggføres i firmware-telemetrien slik at IT-team kan bekrefte at oppdateringen ble fullført rent.
10b. PLC-pakketapsprofil per bruksområde
Ulike bruksområder for lesepenn gir ulike pakketapsprofiler, og PLC-en må være tunet til det verste tilfellet firmwaren vil møte i produksjon. Diagrammet nedenfor knytter de fire primære bruksområdene til det dominerende tapsmønsteret og den PLC-atferden som kreves for å håndtere det rent.
11. Beslutningsmatrise og anbefalinger
[fiks: engelsk-rest] For et helt nytt program som starter i 2026, er anbefalingen å spesifisere Opus-basert PLC på plattformene L5, T2 eller Y6 og kreve PESQ ≥ 3,8 under 30 ms bursttap. For mellomgenerasjons-programmer på K7, KF1, Q6, Q8 er AAC PSOLA PLC akseptabelt, men krev PESQ ≥ 3,4 under samme tapsprofil. For eldre programmer på B1, B2, F8, P2 er den eksisterende bølgeformsubstitusjons-PLC tilstrekkelig for foreldredrevet hjemmebruk, men bør ikke spesifiseres for klasseromsdistribusjoner der Wi‑Fi-sameksistens er konstant.
[fiks: engelsk-rest] For innkjøpere som skriver PLC-spesifikasjonen, lyder avslutningslinjen som lukker kontrakten slik: «Lyddekoderen skal implementere adaptiv PLC som oppnår PESQ ≥ 3,5 under 30 ms bursttap med 5 prosent uniform tilfeldig bakgrunn i henhold til ITU‑T P.862, og PLCQA ≥ 70 under bursttap i henhold til AES PLCQA-standarden, målt på produksjonsfirmware med P.501 referansetalesett ved −26 dBov. OTA-oppdatering skal inkludere demp-og-gjenopptak rundt flash-sektorsletting for å unngå PLC-artefakter.»