DMR, Digital Mobile Radio...

[Marta]

Har googlat desperat efter information i flera dagar, men utan att hitta något. Här finns mycket vetande, så jag hoppas få hjälp att komma vidare. Om Du inte förstår frågan kan Du med 100% säkerhet inte hellre besvara den.

Frågan är hur DMRD frames i i BM's "homebrew repeater protocol" skall hanteras för att få fram AMBE frames att skicka till vocodern.

Jag har kommit så långt som till att skilja ut grupperna med 6 st 33 byte voiceframes, men där är det tvärnit. FEC skall appliceras och resultera i vad jag kan förstå 16 st. 48-bit block som AMBE avkodar till 320ms vanligt digitalljud.

Har letat efter både dokument och exempelkod. Hittat lite, men det är i pyton (urk..) eller c++ som jag har svårt med. Det lilla jag hittat i vanlig c är för rådata från en mottagare. T.ex. dsd-dmr. Inget tycks stämma med antal bytes, så kan inte "passa in" datan.

[guckrum]

Ingen erfarenhet av specifikt denna, men det borde gå att reda ut tycker jag. Är det ETSI TS 102 361 man skall läsa?

[Marta]

Den har med det att göra, men här är data mera "förädlat".

Har sedan första inlägget hittat precis det jag letat efter, till och med inklusive testdata. Dessvärre i python. Tror ändå jag skall satsa på denna och konvertera det till c.

Då skulle det vara till enorm hjälp att få igång python-versionen, men det vill sig inte. Den gnäller över saknad modul som kanske är standard. "No module named bitarray". Antagligen kräker den över mera längre fram...
Hur får jag igång python? Skall förmodligen vara mer på kommandoraden än modul.py?

Här är det jag lyckats hitta: https://github.com/n0mjs710/dmr_utils

Vet någon var motsvarande finns i c så vore det en gudagåva.
Observera att c != c++

[guckrum]

Finns python-bitarray som debianpaket, annars "pip install bitarray" (om du installerar pip först).

[Marta]

Stort Tack!

Nu kör den igenom pytonkoden och det ser rimligt ut. Då återstår "bara" att transkribera det hela till c...

[guckrum]

Om det innefattar turbokodaren lär ju C-versionen bli ett par magnituder snabbare. Kul projekt, lycka till!

[Marta]

Där hänger jag ännu inte med i terminologin på vad som avses. Vet bara att protokollet kallas mototrbo (inget stavfel) och har med Motorola att göra.

Ursprungsfrågan är löst. Det är helt enkelt synk-klumpen som är kvar i dessa frames via nätet. Första och sista 9-gruppen kopieras rakt av och den mellersta "splicas" ihopa efter att 48 bits tagits bort exakt mitt i. Tror jag i varje fall. Finns ett betydligt bättre sätt att göra detta utan bitarray's. Får väl se vad tvärniten blir. Känns helt overkligt att proffsen inte ser att tre logiska operationer rensar ändarna och skarvar ihop det mittersta fältet. Bitsträngen kanske är spegelvänd och motiverar bitarray och en massa shifts, men det såg rätt ut. Märkligt.

Även märkligt hur bristfällig dokumentationen är kring hela BM's protokoll och vissa delar är helt ologiska. Kanske även finns "case sensitivity", men vill inte "bråka" med servern för test. Det hela känns oproffessionellt helt enkelt, men så är det ju också avsett för amatörer...

[Marta]

Nu fungerar programmet delvis, men har problem med buffring. Data kommer in i realtid, 20ms per frame. Dekodern har över 50ms latens. Prövade att sätta upp PulseAudio till att prebuffra 512 samples 8kbit 16-bit mono. Funkar ett kort ögonblick, sedan overrun med >20k i dekoderns buffer. När streamen väl börjat spelas borde den rimligtvis kunna hålla undan ett anyal minuter. Eller är det för optimistiskt att föutsätta bitklockorna löper rätt nog för detta?

Finns det någon standardlösning för detta? Det enda jag kommer på är separata threads. AMBE har en finess för att korta/länga frames med upp till 4 samples, antagligen för sådant ändamål, bara det går att hämta/lämna frames utan att funktionerna blockar. Tyvärr gör Pulse det.

Antar något med buffringsinställningarna är fel. Vad säger experterna?

static const pa_buffer_attr ba ={
.maxlength = -1, //Maximum length of the buffer in bytes.
.tlength = 2, //Playback only: target length of the buffer.
.prebuf = 512, ////Playback only: pre-buffering.
.minreq = 2, //Playback only: minimum request.
.fragsize = 2 //Recording only: fragment size.
};

[Marta]

Gav upp för tillfället att använda buffringen som Pulse tillhandahåller. Gjorde en egen ringbuffer och lade till en extra thread som skyfflar data från denna till Pulse. Nu fungerar det korrekt. Lite lång latens, men ryckigheten i Pulse kräver en stadig buffer. Låter buffringen vila och fortsätter med annat.

[guckrum]

Snyggt!

[Marta]

Tackar, men det här var den lätta delen.

Inkommande data är lätt, bara att droppa allt ovidkommande komplicerat krafs. För att sända måste de 48 bits mitt i bursten genereras korrekt och där skall även vara header/terminator på varje sändning.
På observerade signaler har de flesta även inledande databursts. Vet ej vad detta är. Upprepas tre gånger så tydligen något angeläget att få igenom.

All dokumentation är svår att hitta och jobbig att tolka. Blir helt yr av ETSI-dokumenten med dess hänvisningar till hänvisning till hänv... Får ta penna och papper så kanske det kan flätas ut hur det hänger ihop.

Hade varit bra att få veta vad som är relevant på en IP-terminal, eller bara utfyllnad.

[guckrum]

Vild gissning utan att konsultera specen: kanske är den upprepade preamblen någon form av pilot som används för att skatta kanalen på mottagarsidan?

[Marta]

Har kommit en bra bit nu, men fastnat i faktatorka.
Det gäller datablocket i voice header/terminator. Försöker få ut något vettigt ur dessa, men får bara ut blaj. Eftersom det är bit interleaved är det omöjligt att se några ledtrådar i rådata.

Utföra omstuvningen av bits är inga problem att åstadkomma, frågan gäller mönstret för detta.

Har hittat följande ormsoppa, men är osäker på tolkningen. Någon här som kan python kanske kan hjälpa? T.ex de första 4 bitsen, varifrån tas de och var läggs de sett på det sätt som mallen under koden visar?

Kod: Markera allt

def decode_full_lc(_data):
    binlc = bitarray(endian='big')
    binlc.extend([_data[136],_data[121],_data[106],_data[91], _data[76], _data[61], _data[46], _data[31]])
    binlc.extend([_data[152],_data[137],_data[122],_data[107],_data[92], _data[77], _data[62], _data[47], _data[32], _data[17], _data[2]  ])
    binlc.extend([_data[123],_data[108],_data[93], _data[78], _data[63], _data[48], _data[33], _data[18], _data[3],  _data[184],_data[169]])
    binlc.extend([_data[94], _data[79], _data[64], _data[49], _data[34], _data[19], _data[4],  _data[185],_data[170],_data[155],_data[140]])
    binlc.extend([_data[65], _data[50], _data[35], _data[20], _data[5],  _data[186],_data[171],_data[156],_data[141],_data[126],_data[111]])
    binlc.extend([_data[36], _data[21], _data[6],  _data[187],_data[172],_data[157],_data[142],_data[127],_data[112],_data[97], _data[82] ])
    binlc.extend([_data[7],  _data[188],_data[173],_data[158],_data[143],_data[128],_data[113],_data[98], _data[83]])
    '''
    This is the rest of the Full LC data -- the RS1293 FEC that we don't need
     _data[68],_data[53],_data[174],_data[159],_data[144],_data[129],_data[114],_data[99],_data[84],_data[69],_data[54],_data[39],
    _data[24],_data[145],_data[130],_data[115],_data[100],_data[85],_data[70],_data[55],_data[40],_data[25],_data[10],_data[191]
    '''
    return binlc

bitposition
7 6 5 4 3 2 1 0 byte n
- - - - - -
7 6 5 4 3 2 1 0 byte 1
7 6 5 4 3 2 1 0 byte 0

byte = bitnummer / 8
bitpos = bitnummer % 8

Mycket tacksam för all hjälp.

[guckrum]

bitarray är en array of booleans. Låt oss anta att indatan också är av denna typen. Funktionen skapar en ny array genom att utöka (extend) den nyskapade bitarrayen med bitar från indatan. Utsignalen börjar alltså med bitarna 136, 121, 106, ... från indatan: Utbit[0] = inbit[136], ...
Detta är alltså på "vektornivå" det finns inga "minnesadresser" här.

Omskyffling (interleaving) används för att transmissionsfel ofta påverkar konsekutiva symboler, och felrättande koder (FEC) inte hanterar det så bra. Med omskyffling kommer konsekutiva trasiga symboler att spridas ut så att de inte är nära varandra längre, och då funkar avkodningen mycket bättre.

Ok?

[Marta]

Tackar för svaret.

Så långt är jag me, inget av detta var något nytt för mig.
Problemet är hur bitsträngen är vänd. Det som i pythonprogrammet kallas bit 0, var finns denna? Är den i först eller sist mottagen byte och är det den minst eller mest signifikanta bit i denna sett ur pc-processorns perspektiv?

Jag får försöka lägga till kod i pythonprogrammet och skriva ut en teststräng bit för bit så är det lätt konstaterat hur det är vänt. Ser nu att bitarray skapas big endian och pc är little endian. Antagligen är något felvänt här.