Buggfix Plus
Aktuellt datum och tid: 18.58 2019-12-06

Alla tidsangivelser är UTC + 1 timme




Svara på tråd  [ 12 inlägg ] 
Författare Meddelande
InläggPostat: 10.15 2019-11-30 
EF Sponsor
Användarvisningsbild

Blev medlem: 00.19 2005-03-30
Inlägg: 4750
Ort: Landskrona
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.


Upp
 Profil  
 
InläggPostat: 11.31 2019-11-30 

Blev medlem: 08.04 2012-06-19
Inlägg: 493
Ort: Lund
Ingen erfarenhet av specifikt denna, men det borde gå att reda ut tycker jag. Är det ETSI TS 102 361 man skall läsa?


Upp
 Profil  
 
InläggPostat: 12.19 2019-11-30 
EF Sponsor
Användarvisningsbild

Blev medlem: 00.19 2005-03-30
Inlägg: 4750
Ort: Landskrona
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++


Upp
 Profil  
 
InläggPostat: 12.31 2019-11-30 

Blev medlem: 08.04 2012-06-19
Inlägg: 493
Ort: Lund
Finns python-bitarray som debianpaket, annars "pip install bitarray" (om du installerar pip först).


Upp
 Profil  
 
InläggPostat: 13.04 2019-11-30 
EF Sponsor
Användarvisningsbild

Blev medlem: 00.19 2005-03-30
Inlägg: 4750
Ort: Landskrona
Stort Tack!

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


Upp
 Profil  
 
InläggPostat: 13.30 2019-11-30 

Blev medlem: 08.04 2012-06-19
Inlägg: 493
Ort: Lund
Om det innefattar turbokodaren lär ju C-versionen bli ett par magnituder snabbare. Kul projekt, lycka till!


Upp
 Profil  
 
InläggPostat: 15.37 2019-11-30 
EF Sponsor
Användarvisningsbild

Blev medlem: 00.19 2005-03-30
Inlägg: 4750
Ort: Landskrona
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...


Upp
 Profil  
 
InläggPostat: 14.06 2019-12-01 
EF Sponsor
Användarvisningsbild

Blev medlem: 00.19 2005-03-30
Inlägg: 4750
Ort: Landskrona
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.
};


Upp
 Profil  
 
InläggPostat: 15.55 2019-12-02 
EF Sponsor
Användarvisningsbild

Blev medlem: 00.19 2005-03-30
Inlägg: 4750
Ort: Landskrona
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.


Upp
 Profil  
 
InläggPostat: 19.40 2019-12-02 

Blev medlem: 08.04 2012-06-19
Inlägg: 493
Ort: Lund
Snyggt!


Upp
 Profil  
 
InläggPostat: 09.19 2019-12-03 
EF Sponsor
Användarvisningsbild

Blev medlem: 00.19 2005-03-30
Inlägg: 4750
Ort: Landskrona
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.


Upp
 Profil  
 
InläggPostat: 11.48 2019-12-03 

Blev medlem: 08.04 2012-06-19
Inlägg: 493
Ort: Lund
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?


Upp
 Profil  
 
Visa inlägg nyare än:  Sortera efter  
Svara på tråd  [ 12 inlägg ] 

Alla tidsangivelser är UTC + 1 timme


Vilka är online

Användare som besöker denna kategori: Inga registrerade användare och 1 gäst


Du kan inte skapa nya trådar i denna kategori
Du kan inte svara på trådar i denna kategori
Du kan inte redigera dina inlägg i denna kategori
Du kan inte ta bort dina inlägg i denna kategori
Du kan inte bifoga filer i denna kategori

Sök efter:
Hoppa till:  
   
Drivs av phpBB® Forum Software © phpBB Group
Swedish translation by Peetra & phpBB Sweden © 2006-2010