DMR, Digital Mobile Radio...

C, C++, Pascal, Assembly, Raspberry, Java, Matlab, Python, BASIC, SQL, PHP, etc.
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6887
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: DMR, Digital Mobile Radio...

Inlägg av Marta »

Nu är det testat.

Med första byte som läses in av bitarray i python satt till 0x01 så sätts bit# 7.
Bitföljden i bytes är alltså omkastad!!!! Tro f*n att resultatet blev blaj.

Jag blir yr... Det är verkligen python...
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: DMR, Digital Mobile Radio...

Inlägg av xxargs »

hmm det de kallar CRC är ingen CRC- bara en checksumma och CRC resp. checksumma är två helt olika saker i min bok.

Både CRC och checksumma finns dessutom i otal varianter för att hantera olika typer av bitfelsmönster, så använda algoritm/polynom bör också alltid anges.

har man möjlighet att välja så skall man alltid använda CRC (med angiven polynom) framför checksumma för att minimera risken för oupptäckta fel.
guckrum
Inlägg: 1669
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: DMR, Digital Mobile Radio...

Inlägg av guckrum »

Jag blir yr... Det är verkligen python...
Javisst! Såhär tycker jag att det alltid blir när man implementerar standarder som dessa! Vilket håll far bitarna? Var är LSB i varje ord? Vilket håll skall polynomet vara? Ibland är det enklast att prova sig fram, men säg inte att jag har sagt det...
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6887
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: DMR, Digital Mobile Radio...

Inlägg av Marta »

Det är riktig CRC på datablocket, 9 byte data och 3 byte CRC. Polynomen finns i ETSI-dokumenten angående DMR.

Därefter FEC-kodas hela fältet på 96 bits så slutresultatet blir 196 bits. Dessa interleavas sedan samt delas i två block på vardera 98 bytes. Mitt emellan läggs ett block som innehåller en synk eller embedded data eller filler. Det är mycket att hålla reda på...

Till att börja med så saknar jar hur FEC skall avkodas, så det blir som i python-programmet att bara rensas bort FEC. Får se hur det fungerar. De här datablocken är föga nödvändiga i en IP-terminal vid mottagning. Vid sändning skall de finnas där. Har algoritmer för det i python. Nu skall det nog vara lite lättare att tolka detta skitspråk och transkribera till c.

Nu funkar den förenklade avkodningen som den skall. Det var bakvänd ordning som var hela problemet. Det är fortfarande lite bakvänt på en PC, allt kommer ut big endian. Blir att antingen hantera detta eller vända tabellen för avkodning.


Det där med att prova är så det får bli. Återstår mycket än. Utöver dessa headers är där embedded block som måste genereras. Är bara synken som kan tas från tabell. Har testdata och förhoppningsvis korrekta algoritmer, dessvärre i python. Hittar märkligt nog nästan inget i c. Kanske har att göra med bithanteringen som finns klar i vissa skitspråk.
Användarvisningsbild
ffredrik
Inlägg: 340
Blev medlem: 20 oktober 2009, 17:52:18
Ort: Göinge

Re: DMR, Digital Mobile Radio...

Inlägg av ffredrik »

"...att tolka detta skitspråk och transkribera till c" :tumupp: :tumupp: :D
guckrum
Inlägg: 1669
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: DMR, Digital Mobile Radio...

Inlägg av guckrum »

Har du en länk till var FECen finns beskriven? Hittar bara att den är "state-of-the-art"...
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: DMR, Digital Mobile Radio...

Inlägg av xxargs »

Marta skrev:Det är riktig CRC på datablocket, 9 byte data och 3 byte CRC. Polynomen finns i ETSI-dokumenten angående DMR.
måhända - men det är inte det som sker i crc.py utan det gör bara en 5-bitars checksumma av 9 byte på enklast tänkbara sätt och sedan lite knöl av summan efter (bla modulo 31 och omvandla till asciivärde) om jag tolkar 'skitspråket' rätt.

efter att ha läst i TS 102 361-1 v1.2.1 så verkar det bara vara B3.11 "5-bit Checksum (CS) calculation" som är implementerad i filen crc.py, inget mer.

förmodligen är filen tänkt att samla en bunt olika checksumme och CRC-algoritmer men har bara implementerar ett enda av det.

---

Det verkar som att det är en hel del jobb kvar att göra i den här paketet och i nuläget så skippar man det mesta av de felrättande och kontrollerande funktioner som finns inbyggt i protokollet på mottagarsidan men var tvungen att implementera mycket mer på de utsända paketen för att det skulle sväljas av andra DMR-mottagare gissar jag.

@guckrum - Annex 'B' avsnitten lång bak i TS 102 361-1 v1.2.1 verka beskriva det du frågar efter - men det är ju inte någon källkod precis...
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6887
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: DMR, Digital Mobile Radio...

Inlägg av Marta »

Det står uttryckligen någonstans i materialet från ormgubben att han inte implementerar FEC. I scriptet för deinterleave har han denna kommentar "This is the rest of the Full LC data -- the RS1293 FEC that we don't need" Här kallar han dessutom CRC (enligt ETSI's färggranna figurer) för FEC.

FEC är över mitt huvud. Jag förstår vad pariteter och bitsummor på längden och bredden är och att dessa kan peka ut bitflips, men de avancerade metoder som används i kvalificerade sammanhang är 100% black magic.
guckrum
Inlägg: 1669
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: DMR, Digital Mobile Radio...

Inlägg av guckrum »

Det jag kan tänka krävs som minimum på sändarsidan är att bitarna blir tillräckligt "scramblade" så att symbolerna inte sänds med bias, dvs att medelvärdet av bitarna är noll. Man skall kunna skicka en konstant sekvens och ändå få tillräckligt med symbolbyten för att RF-delarna skall funka. Generellt sett, alltså.
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6887
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: DMR, Digital Mobile Radio...

Inlägg av Marta »

Antagligen har Du rätt där. Ormgubben skriver att embedded-blocken kan tabellgenereras. Synkarna är ju tabell och idle fillers som skall ha en föreskriven pseudorandom kan nog i praktiken tas från en tabell, eller en handfull olika.
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6887
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: DMR, Digital Mobile Radio...

Inlägg av Marta »

Får inga bra träffar bär jag googlar på hamming 15,11,3. Någon som har en länk till en sida om denna variant utan universitetsprat? Känner inte igen bitsekvenserna för paritet i pythonkoden.

csum[0] = _data[0] ^ _data[1] ^ _data[2] ^ _data[3] ^ _data[5] ^ _data[7] ^ _data[8]
csum[1] = _data[1] ^ _data[2] ^ _data[3] ^ _data[4] ^ _data[6] ^ _data[8] ^ _data[9]
csum[2] = _data[2] ^ _data[3] ^ _data[4] ^ _data[5] ^ _data[7] ^ _data[9] ^ _data[10]
csum[3] = _data[0] ^ _data[1] ^ _data[2] ^ _data[4] ^ _data[6] ^ _data[7] ^ _data[10]

Hade väntat mig dessa med lsb = bit0 och paritetsbitarna på separat plats

0 1 3 4 6 8 10
0 2 3 5 6 9 10
1 2 3 7 8 9 10
4 5 6 7 8 9 10
guckrum
Inlägg: 1669
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: DMR, Digital Mobile Radio...

Inlägg av guckrum »

Kolla "Table B.15: Hamming (15,11,3) generator matrix".

De fyra sista kolumnerna är paritetsbitarna. Kalla dem p3, p2, p1, p0.

Läs p3 uppifrån 11110101100 = [b0, b1, b2, b3, b5, b7, b8]
Jämför: csum[0] = _data[0] ^ _data[1] ^ _data[2] ^ _data[3] ^ _data[5] ^ _data[7] ^ _data[8]

Osv för p2, p1 och p0.
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6887
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: DMR, Digital Mobile Radio...

Inlägg av Marta »

Hittade denna nu, Tack.

Jag är hyfsat nollställd på de här koderna. Inser nu att dokumentet per definition bestämmer vilka bits pariteten skall tas på. Hade låst mig i missuppfattningen at hamming code alltid var detta: http://users.cis.fiu.edu/~downeyt/cop3402/hamming.html
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6887
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: DMR, Digital Mobile Radio...

Inlägg av Marta »

Det tog ett tag, med mycket påtvingade pauser för invalidbestyr, men nu fungerar hamming code och interleave. I och för sig enkelt, men att vända allt rätt samt inte minst fiska upp mellanvärden ur ormsoppan var knappast trivialt...

Nu återstår CRC, eller rättare reed-solomon som det visade sig vara.
Transkriptionen från python funkar inte, har svårt med vad pythonfunktionerna gör. Vore mycket tacksam om någon som kan både c och python kunde ge lite hjälp.

Kod: Markera allt

# Reed-Solomon (12,9) encoder
def encode(_msg):
    assert len(_msg) == 9, 'RS129_encode error: Message not 9 bytes: %s' % print_hex(_msg)

    parity = [0x00, 0x00, 0x00]

    for i in range(NUM_BYTES):
        dbyte = _msg[i] ^ parity[NPAR - 1]
        for j in range(NPAR - 1, 0, -1):
            parity[j] = parity[j - 1] ^ log_mult(POLY[j], dbyte)
        parity[0] = log_mult(POLY[0], dbyte)
    return [parity[2], parity[1], parity[0]]

Kod: Markera allt

// Reed-Solomon (12,9) encoder
void encode(uchar* rs, uchar* _msg){

  const uchar NUM_BYTES = 9;
  const uchar NPAR = 3;
  uchar POLY[] = {64, 56, 14, 1, 0, 0, 0, 0, 0, 0, 0, 0};
  static uchar parity[3];
  int i,j;
  uchar dbyte;

    memset(parity, 0, 3);

    for (i=0; i<NUM_BYTES; i++){
        dbyte = _msg[i] ^ parity[NPAR - 1];
        for (j=NPAR - 1; j>0; j--)
            parity[j] = parity[j - 1] ^ log_mult(POLY[j], dbyte);
        parity[0] = log_mult(POLY[0], dbyte);
    };
    dbyte=parity[0]; parity[0]=parity[2]; parity[2]=dbyte;
    //return [parity[2], parity[1], parity[0]]
};
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6887
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: DMR, Digital Mobile Radio...

Inlägg av Marta »

Finns det någon debugger till python för att exekvera scriptet steg för steg och ha höjlighet att se alla variabler mellan stegen?
Skriv svar