DMR, Digital Mobile Radio...
Re: DMR, Digital Mobile Radio...
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...
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...
Re: DMR, Digital Mobile Radio...
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.
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.
Re: DMR, Digital Mobile Radio...
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...Jag blir yr... Det är verkligen python...
Re: DMR, Digital Mobile Radio...
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.
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.
Re: DMR, Digital Mobile Radio...
Har du en länk till var FECen finns beskriven? Hittar bara att den är "state-of-the-art"...
Re: DMR, Digital Mobile Radio...
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.Marta skrev:Det är riktig CRC på datablocket, 9 byte data och 3 byte CRC. Polynomen finns i ETSI-dokumenten angående DMR.
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...
Re: DMR, Digital Mobile Radio...
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.
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.
Re: DMR, Digital Mobile Radio...
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å.
Re: DMR, Digital Mobile Radio...
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.
Re: DMR, Digital Mobile Radio...
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
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
Re: DMR, Digital Mobile Radio...
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.
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.
Re: DMR, Digital Mobile Radio...
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
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
Re: DMR, Digital Mobile Radio...
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.
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]]
};
Re: DMR, Digital Mobile Radio...
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?