[MTCB-MTCD][PX2 - PX3][Autoradio Android] Problema AF - Cerchiamo una soluzione

[Marco589]

Fammi capire che problemi da?

Inviato dal mio LG-D802 usando Androidiani App

L'ho riprovata, ha trovato alcune stazioni
Domani provo l'ultima versione che hai linkato

[sabruri1]

L'ho riprovata, ha trovato alcune stazioni
Domani provo l'ultima versione che hai linkato

http://forum.xda-developers.com/andr...x-apk-t3060854

Questa è la via...

[Tom78]

Raga io ho chiesto ad un mio amico che fa il radio amatore.....mi ha detto che la funzione Af funziona in questo modo : le stazioni radio trasmettono un segnale nel sistema RDS che la radio va a cercare per sintonizzarsi sula frequenza più forte.....quindi la App deve memorizzare questo campo RDS per esempio nel posto dove è stato memorizzata la stazione in maniera anche di andarla a cercare se accendendo la radio la frequenza non è presente

[sabruri1]

Raga io ho chiesto ad un mio amico che fa il radio amatore.....mi ha detto che la funzione Af funziona in questo modo : le stazioni radio trasmettono un segnale nel sistema RDS che la radio va a cercare per sintonizzarsi sula frequenza più forte.....quindi la App deve memorizzare questo campo RDS per esempio nel posto dove è stato memorizzata la stazione in maniera anche di andarla a cercare se accendendo la radio la frequenza non è presente

Noi non avendo il secondo tuner ci dobbiamo "arrangiare" diversamente xD

[pk313]

Noi non avendo il secondo tuner ci dobbiamo "arrangiare" diversamente xD

La frequenza non è presente ...diciamo...a metà. . con le vecchie versioni quella che avevo a giugno 2014 quando lho presa ...appena il segnale si abbassava. ..spariva il nome rds dalle memorie e dalla schermata principale...ora con le ultime versioni...l'ultima in particolare ...sui tasti memorizzati rimangono e quella in ascolto deve arrivare a sparire quasi del tutto.per perdere il nome...prima la sensibilità era parecchio più bassa...non so che abbiano migliorato...
Il problema ho sempre pensato fosse lì anch'io. .come se la app non ricordasse che a Quell rds ricevuto deve abbinare la serie di frequenze che il tuner ha immagazzinato x poi dirgli di cercare quella che si sente...
Se guardate il datasheet che ho postato si vede nella serie di grafici relativi all rds che quando il pll interno riceve il primo blocco di dati li stiva fino a un nuovo comando esterno...il tuner fa tutto da solo..basta che abbia l'ordine di farlo qst è il problema al sistema è sufficiente un segnale poco superiore a quello stereo per essere attivo.
È come se venissero prelevati e letti i dati rdr solo in modo visivo ma il tuner non ha l'input x sapere che deve cambiare da solo frequenza
Comunque. ..un solo tuner sarà solo più lento nel cambio e lascerà dei mSecondi di vuoto .come si sente su alcune autoradio..le frazioni che gli servono a decidere la giusta frequenza e vederne il livello...
Nei doppi tuner questo lavoro viene fatto da uno mentre l'altro lavora normalmente quindi senza interruzioni tra un cambio e l'altro
Bisogna lavorare proprio su come la app governa e dice al tuner che fare con l'rds..
Non so se mettendo a confronto le prime versioni di mtcradio...e le ultime che già perlomeno qualcosa conservano si possa capire dove agire...

[sabruri1]

La frequenza non è presente ...diciamo...a metà. . con le vecchie versioni quella che avevo a giugno 2014 quando lho presa ...appena il segnale si abbassava. ..spariva il nome rds dalle memorie e dalla schermata principale...ora con le ultime versioni...l'ultima in particolare ...sui tasti memorizzati rimangono e quella in ascolto deve arrivare a sparire quasi del tutto.per perdere il nome...prima la sensibilità era parecchio più bassa...non so che abbiano migliorato...
Il problema ho sempre pensato fosse lì anch'io. .come se la app non ricordasse che a Quell rds ricevuto deve abbinare la serie di frequenze che il tuner ha immagazzinato x poi dirgli di cercare quella che si sente...
Se guardate il datasheet che ho postato si vede nella serie di grafici relativi all rds che quando il pll interno riceve il primo blocco di dati li stiva fino a un nuovo comando esterno...il tuner fa tutto da solo..basta che abbia l'ordine di farlo qst è il problema al sistema è sufficiente un segnale poco superiore a quello stereo per essere attivo.
È come se venissero prelevati e letti i dati rdr solo in modo visivo ma il tuner non ha l'input x sapere che deve cambiare da solo frequenza
Comunque. ..un solo tuner sarà solo più lento nel cambio e lascerà dei mSecondi di vuoto .come si sente su alcune autoradio..le frazioni che gli servono a decidere la giusta frequenza e vederne il livello...
Nei doppi tuner questo lavoro viene fatto da uno mentre l'altro lavora normalmente quindi senza interruzioni tra un cambio e l'altro
Bisogna lavorare proprio su come la app governa e dice al tuner che fare con l'rds..
Non so se mettendo a confronto le prime versioni di mtcradio...e le ultime che già perlomeno qualcosa conservano si possa capire dove agire...

Ripeto, il problema sta semplicemente nel fatto che nell'app NESSUNO e dico NESSUNO gestisce le AF. Vi spiego cosa succede alla pressione del tasto AF; l'activity associata alla gui, va a dire alla RadioService: oh guarda che devi attivare l'AF perché l'utente la desidera!
RadioService da buon esecutore di comandi, piglia e passa l'informazione all'AudioManager (una libreria di android) mediante una stringa del tipo "tuner_rds_af_Start". Dopo ciò nulla! Niente di niente, la classe RadioService si disinteressa completamente della funzione. Cosa che invece NON AVVIENE con le altre funzioni PTY e AutoSearch.

Vi dico qual è la soluzione che adatterò quando riuscirò a compilare i file .java XD

Dunque, entrambe le funzioni PTY e AutoSearch, nella classe RadioService vengono gestiti con dei Runnable (per chi conosce i Thread di java sa di cosa parlo). Entrambe le funzioni fanno dei controlli periodici (ogni 60ms, 100ms e 1000ms) per vedere lo stato del segnale (l'autosearch) e i notiziari (PTY).

Io implementerò l'AF allo stesso modo, ovvero con dei Runnable che controllano periodicamente la potenza del segnale. Nel momento in cui questa potenza diventerà minore di una certa soglia, allora metterò in MUTE la radio e verificherò le potenze delle frequenze alternative (per farlo ho bisogno di sintonizzarmi su ognuna frequenza alternativa e leggerne la potenza). Dopo aver fatto ciò (un paio di ms di mute) sintonizzerò la radio sulla frequenza con potenza maggiore e leverò il MUTE. Ovviamente con tutti i controlli del caso...per esempio se è attiva l'autosearch, l'af non deve partire altrimenti succede un bordello!

Con le radio a un solo tuner di più secondo me non si può fare...ma se avete altre idee dite pure!

[pk313]

Ripeto, il problema sta semplicemente nel fatto che nell'app NESSUNO e dico NESSUNO gestisce le AF. Vi spiego cosa succede alla pressione del tasto AF; l'activity associata alla gui, va a dire alla RadioService: oh guarda che devi attivare l'AF perché l'utente la desidera!
RadioService da buon esecutore di comandi, piglia e passa l'informazione all'AudioManager (una libreria di android) mediante una stringa del tipo "tuner_rds_af_Start". Dopo ciò nulla! Niente di niente, la classe RadioService si disinteressa completamente della funzione. Cosa che invece NON AVVIENE con le altre funzioni PTY e AutoSearch.

Se mi seguite vi pongo la soluzione che adatterò quando riuscirò a compilare i file .java XD

Dunque, entrambe le funzioni PTY e AutoSearch, nella classe RadioService vengono gestiti con dei Runnable (per chi conosce i Thread di java sa di cosa parlo). Entrambe le funzioni fanno dei controlli periodici (ogni 60ms, 100ms e 1000ms) per vedere lo stato del segnale (l'autosearch) e i notiziari (PTY).

Io implementerò l'AF allo stesso modo, ovvero con dei Runnable che controllano periodicamente la potenza del segnale. Nel momento in cui questa potenza diventerà minore di una certa soglia, allora metterò in MUTE la radio e verificherò le potenze delle frequenze alternative (per farlo ho bisogno di sintonizzarmi su ognuna frequenza alternativa e leggerne la potenza). Dopo aver fatto ciò (un paio di ms di mute) sintonizzerò la radio sulla frequenza con potenza maggiore e leverò il MUTE. Ovviamente con tutti i controlli del caso...per esempio se è attiva l'autosearch, l'af non deve partire altrimenti succede un bordello!

Con le radio a un solo tuner di più secondo me non si può fare...ma se avete altre idee dite pure!

Non fa una piega.. ...esattamente cio che intendo ...l'unica cosa qst tuner ha l'automute attivo quindi manco quello dovrebbe servire
C'è una sola variabile...da considerare in più. ..che va scritto anche il livello di segnale a cui lavorare...
Af attivo...non parto a cercare altre frequenze finché il livello segnale è sceso fino a un tot....il tuo lavorare sull autoseach ha senso chiaramente...x capire
Af spento...non faccio nulla

He...qst lo sa gia fare la radio

[sabruri1]

Non fa una piega.. ...esattamente cio che intendo ...l'unica cosa qst tuner ha l'automute attivo quindi manco quello dovrebbe servire
C'è una sola variabile...da considerare in più. ..che va scritto anche il livello di segnale a cui lavorare...
Af attivo...non parto a cercare altre frequenze finché il livello segnale è sceso fino a un tot....il tuo lavorare sull autoseach ha senso chiaramente...x capire
Af spento...non faccio nulla

He...qst lo sa gia fare la radio

Sul tenerlo spento penso sia l'unica cosa su cui non dovremo lavorare ahahahah comunque io ho scritto a xda per capire come interfacciare il loro tool dexpatcher con android studio, perché veramente non si capisce nulla! Non hanno messo nemmeno un briciolo di doc su questo!

[pk313]

Sul tenerlo spento penso sia l'unica cosa su cui non dovremo lavorare ahahahah comunque io ho scritto a xda per capire come interfacciare il loro tool dexpatcher con android studio, perché veramente non si capisce nulla! Non hanno messo nemmeno un briciolo di doc su questo!

Cmq dall open source di spirit2 proprio non si riesce ad avere un idea anche vaga di come viene eseguita la funzione?

[sabruri1]

Cmq dall open source di spirit2 proprio non si riesce ad avere un idea anche vaga di come viene eseguita la funzione?

E' che il core dell'app è in C...e io sono messo maluccio, anche perché fa chiamate molto strane. Anche lui ha ammesso che il suo codice è molto incasinato. Nel readme (tra l'altro più che un readme è un lamento sul fatto che ha lasciato il suo lavoro per dedicarsi completamente a spirit e che ci guadagna pochissimo lavorando il doppio) giustifica il caos del codice dicendo: tanto nella realtà avrete sempre a che fare con codice incasinato...alla mia email ha risposto che oramai non si ricorda più come faceva a gestire l'af.