En RS _encoder_ är relativt "enkel". (Avkodning är lite värre, vi kan spara den till senare.) Det en encoder gör är att beräkna värdet på ett polynom
P = x0 + x1*a + x2*a*a + x3*a*a*a ...
där x0...xN är din indata och a är en konstant. Denna beräkning utförs för några olika konstanter a och resultaten är "paritetsinformationen". I ditt fall har du tre paritetsord.
Alla beräkningar sker i en Galoiskropp, där ett tal är till exempel åtta bitar, addition motsvaras av bitvis exor, och multiplikation görs via tabelluppslag. Notera att a*a*a... typiskt beräknas rekursivt för polynomet ovan, så inga exponeringar behövs.
Okulärt ser kodsnuttarna "lika" ut. Kan du inte snabbt bara printa de tre variablerna i "parity" för några iterationer? På ormspråk heter det "print()"
Nu är det löst.
Ormtjusaren hade valt ett onödigt stökigt sätt att implementera det på. Dessutom kastat om de två mellersta nibbles i jämförelsevärdet.
Hade gjort en idiottabbe i den magiska multiplikationen, men där är mera fel än det.
Hittade en annan variant och den fungerade. Blev först yr av nämnda typo, men nu funkar det. Börjar närma sig, men mycket återstår...
Har kommit en bit längre nu, men fastnat på en ny checksumma. Allt innehåll är nu klart vad det skall vara och inkommnde "embedded data" läses av. Det är en blandning av addressblock och en liten textsträng som kan konfigureras av användaren.
Det följande är BLAJ!
Vad det än är utöver sync eller null så skall det ha en sådan här:
ETSI TS 102 361-1 B.3.2 Quadratic residue (16,7,6)
G(x) = x8 + x5 + x4 + x3 + 1 = 4718
qr-16-7-6.jpg
Mycket tacksam för en steg,för,steg anvisning hur den tas fram. Det finns ett polynom och en ruta med en matris i dokumentet. Hur det skall resultera i 5 checkbits är dessvärre bortom vad min kvarvarande IQ kan få ihopa[/s]...
/BLAJ!
Ber om ursäkt för mitt misstag. Denna checksumma gäller ett 7-bit kontrollfält och kan läsas från tabell, eller hela klumpen ligga färdig i de 4 varianter som krävs.
Det stora datafältet är en aritmetisk checksumma %31 (trettioett) för att få de 5 bits...
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Jodå, RS-encodern behövs för att skapa header/terminator och de innehåller föränderlig info och kan inte tas från tabell. Alla dataframes skall ha denna. Kommer antagligen även att behövas för annan data när det blir aktuellt. En dataframe tycks alltid innehålla en sync från tabell i platsen för embedded data.
När något däremot fragmenteras i 4 delar och går som embedded i en serie voiceframes så är RS utbytt mot ovan nämnda checksumma.
Voice sänds i grupper om 6 frames. Första har en sync, nästa fyra embedded data och sista null. Kring embedded data finns info om det är ensamt, första, mitt i eller sista block Där finns även "color code" som separerar nät som kan höra varandra. Inte aktuellt via internet. Därför behövs inte quadratic residue, enklare med tabell för de fyra alternativen.
Nu är alla checksummor och "bitsnurror" klara och verifierade, men återstår ändå en hel del än innan det är klart att sända. Bl.a. BM's egen header och att kombinera ihop allt.
Även audiobuffringen måste det göras något åt. Har en alldeles för lång cirkulär buffer på 4 sek. och ändå problem. Det låter helt rätt, men blir täta hack där taltid försvinner ca 10 (8?) sek åtskilda som om inpekaren körde över utpekaren. Det är ju omöjligt för det borde låta sk*t om vocoder och uppspelare inte har samma format. Blir helt yr av denna buffring.
Nu har jag tagit tag i buffringsproblemet och loggat till fil vad som sker. Problemet är att det råder en brutal osynk mellan vocoder och ljudkort. Det kommer in samples mycket fortare än de spelas upp med resultat att ringbuffern "biter sig i svansen".
Skillnaden är stor. Det år 8k/s 16-bit samples och buffern är 64k. På ungefär 360ms växer slacken med drygt 1k.
Det här är ett problem jag aldrig haft anledning att fundera på, men måste ju finnas vid all uppspelning av streams. Alltså finns det även en väl utvecklad lösning. Hur och var? Hands on, inget universitetsprat.
Skampålen nästa... Jag är för gammal nu antagligen.
Problemet är löst och det var min egen bug, givetvis.
"Övermatade" vocodern som hanterade det som en störd frame och producerade alldeles för många samples utan att det lät sk*t.
Nu börjar det bli klart med kommunikationsdelen av programmet. Hade hoppats det skulle bli till jul, men någon bit sitter fortfarande på tvären.
Mottagningen fungerar nu helt som den skall, sedan en kvarglömd rad för teständamål avlägsnats.
Sändningen fungerar så långt att mitt DMR-ID kommer upp på BM's webmonitor, men hörs inte något alls... Antar det räcker med att BM's egen header är OK för detta, även om medföljande DMR-packet smakar pyton.
Antagligen är det en liten småsak som är fel, gäller "bara" att hitta den. Om det vocodern matar ut är OK vet jag inte, ser ut som ren ciphertext, men mönstret av det ändras av ljud i mikrofonen. Kanske måste skriva testkod för att lagra vocoderdata och skicka tillbaka till mottagningsprogrammet.
Sk*t att den kostar drygt 1k, hade behövt två nu.
Nåväl, får fortsätta dissikera DMR-packets medan Ni andra sprätter upp julklappspaket. Hittils har varje bit suttit där (tror jag...) den skall sitta, men något måste ju vara fel.
Skulle behöva en UDP-sniffer som sparar datadelen av packets som två hexnummer per byte. Inte bokstäver eller prickar för nonprintables. Helst inte hellre UDP-overhead. Har ett sk*tprogram för windows som skulle kunna ge referensdata. Kan ju vara själva innehållet i ett block som är fel, även om interleavern snurrar bitsen på rätt sätt. Har aldrig sett en garanterat OK utgående packet, bara inkommande.
Kom på den lysande iden att köra loopback så programmet avkodar sin egen txstream. Fungerar fint och allt ser OK ut. Tack vare den enorma ljudbuffern från tidigare strul ekar den tillbaka från miken också, därmed är vocoderns sändfunktion och rättvänd vocoderdata verifierat.
Fick en plötslig ingivelse. Alla tycks ha en talker ID där första ordet är deras signal. Lade till denna och allt fungerar. Mastern tycks klippa signalen om den saknas. Legala skäl kanske?
Tänk om det hade funnits en vettig spec där allt finns med, klart och entydigt.
Stort Tack till alla som hjälpt till.
Nu återstår UI och tillhyfsning, men alla detaljer är på plats.
Det funkar! Men det verkar vara en standard med många hörn. Jag brukar göra som du, ordna med loopback först. Man kan köra loopback på varje komponent för sig först, för att snabba upp debug, tex vocoder för sig, interleaver för sig osv... Därefter är det så snabbt som möjligt riktig signal som gäller. Och du är ju där nu. Frågan nu är alltså hur mycket av standarden du behöver täcka för att ta emot "allt".
