Newsgroup: it.comp.reti.wireless
Titolo: [Tecno] Una soluzione senza CS8130, per lunghe distanze.

Salve!
Ecco una possibile idea per non utilizzare il CS8130.
Questa soluzione e' praticamente terminata a livello hardware, infatti
ho gia' i circuiti adatti (che richiedono solo una modifica per
ampliare la banda passante).
Tutto il lavoro sta nella parte software.
Innanzitutto questa soluzione puo' funzionare praticamente solo sotto
Linux, perche' solo li e' possibile scrivere i moduli per il kernel
senza farsi venire la barba bianca.
Veniamo al dunque.
Questa soluzione usa una scheda audio controllata a
cristallo(generalmente una soundblaster) come dispositivo DSP
e trasmette il segnale su un trasmettitore laser in FM.
Il trasmettitore potrebbe essere quello di Nuova Elettronica, ma
modificato per portare la banda passante da 10 a 23KHz e la portante
da 40 a 100KHz.
Un simile ricetrasmettitore dovrebbe costare sulle 100Klire diodo
laser incluso.
E' FM per i soliti motivi: allunga la vita del diodo laser ed e' poco
sensibile alle turbolenze atmosferiche.
Adesso veniamo alla scheda audio.
La SB campiona il segnale a 44100Hz e 16bit (facciamo 12bit per la
SB16) e quindi potenzialmente puo' disporre di una banda molto grande.
Se le cose fossero cosi' semplici sarebbe fatta... non e' cosi'.
Con un SB non possiamo usare una modulazione standard come la FSK: 
al massimo ci potremmo fare appena 19200bps se va bene.
Questo sistema torna utile se possiamo farci piu' di 115Kbps,
altrimenti tanto vale tenerci il CS8130 che ' piu' economico.
Ok, cio' che non va bene con la FSK e' che si tratta di una
modulazione robusta e semplice, ma non molto efficiente.
Il nostro e' chiaramente un canale limitato in banda: bisogna usare
quindi una modulazione che ottimizzi la banda.
La disponibilita' di una Sound Blaster ci permette di realizzare cose
impensabili e prima assolutamente non realizzabili con circuiti
discreti come quelli dei modem radioamatoriali.
Ho progettato per la Sound Blaster uno schema di modulazione ibrido a
due strati.
Il primo strato e' una variante della modulazione PAM (Pulse Amplitude
Modulation) ed e' il vero nucleo di questa tecnologia.
Il secondo strato e' realizzato in modo trasparente nell' RTX in FM ed
e' la conversione da PAM ibrida a MFSK (Multiple Frequency Shift
Keying).
 
Descriviamo questa PAM ibrida.
Una simile modulazione non e' proprio una vera PAM, infatti e' un
qualcosa gestibile solo via DSP.
Sostanzialmente abbiamo una portante a 10KHz: ogni *semionda* di
questa portante ha una ampiezza diversa che codifica il simbolo
trasmesso.
Ho previsto simboli fino a 8 bit , il che significa che noi
campioniamo a  16bit ogni semionda e ognuna ha 256 ampiezze possibili.
IL che significa che possiamo arrivare fino ad un bit rate di 160Kbps
con una banda di 20KHz.
Ora, sarebbe imopossibile realizzare in componenti discreti una cosa
simile.
Infatti tutto e' via DSP: all'inizio di ogni pacchetto e' prevista una
sezione con una portante di ampiezza massima e poi decrescente 16
livelli per volta.
In questo modo troviamo i punti di zero-crossing risolvendo un sistema
trascendente a tre equazioni banalizzato a due e possiamo anche
normalizzare le ampiezze di picco. Tutto questo serve a
autosicronizzare il sistema DSP sulla portante. Ottenuta una prima
sincronia si effettua un perfezionamento dei dati mediando su piu'
campioni.
POi inizia la vera trasmissione: ottenuto un campione e la posizione
temporale del punto di attraversamento dello zero (zero-crossing) 
e' possibile effettura una interpolazione sinusoidale e trovare
l'ampiezza di picco della semionda.
Si noti che tra una semionda e l'altra vi e' una discontinuita' di
primo tipo (cmq e' una linea spezzata ma senza salti) su cui si
concentra la maggiora parte dell'alta frequenza.
Ovviamente un potremo mai campionare questa discontinuita' , eliminata
dall'anti-aliasing.
Il fatto che localmente la forma d'onda sia sinusoidale, pero' ci
aiuta, infatti se e' vero che l'antialiasing genera una deformazione
dell'onda,il fatto di averla resa quasi-sinusoidale ci permette di
minimizzare l'errore.
 Inoltre ricordando che all'inizio avevamo preparato una scala per la
normalizzazione basandoci su dati reali possiamo essere relativamente
tranquilli.
Questa modulazione, mi duole dirlo e' realizzata attraverso impulsi
ideali. Il ricevitore pero' non potra' riceverla come vermanete e' e
questo genera errori.
Io penso comunque che sia possibile anche usare impulsi non ideali con
un fronte di salita finito: e' infatti possibile incorporare i
suddetti nella forma d'onda e filtrarli realizzando il fintrlo inverso
al ricevitore.
 
A proposito, ho idea che un simile schema di modulazione sia usato
altrove, comunque io penso che non sia affatto malvagio.
A proposito, ovviamente si puo' ridurre il numero dei bit trasmessi:
potremmo anche andare a 6bit per impulso e ottenere 120Kbps.
Tutto sta nel ridurre gli errori e nel livello del rumore.
A proposito, a 1.5KHz, cioe' con un CB, ad es. si potrebbero  ottenere
comodamente 19k2 bps.
A, ecco l'ultima cosa: 
matematicamente e' tutto pronto e non e' affatto pesante, c'e' solo da
metterlo in codice sorgente e scrivere il modulo del Kernel.....
In teoria si potrebbero fare distanze molto piu' lunghe, probabilmente
10-20Km senza problemi.
Nospam

 wrote in message 380ef118...@news.remarq.com...
| Salve!
|
| Ecco una possibile idea per non utilizzare il CS8130.
bhe...  in effetti sto' pensando una cosa...  sto' coso quiì (CS8130) nel
DataSheet c'è scritto che può essere usato per applicazioni IrDA e in
effetti nel laser link lo si usa proprio così... ma allora se 2+2 fa' 4 dai
pin della scheda madre dovrebbero uscire esattamente le stesse cose che
escono dal chip...   quindi le collisioni ey simila sono gestite dal
protocollo FastIr (se si è sotto Win9x) ... ma tralasciando le collisioni
(che abbiamo appurato che ormai col sistema della lente "dovrebbero" essere
risolte) possiamo veramente fare a meno dell'ormai famoso chip...   e si
potrebbero invece ritornare utili gli ormai "ignorati" pin della IrDA sulla
MB (eventualmente si potrebbe costruire un coso modulare del tipo che se non
hai la MB con l'IrDA basta sggiungere una schedina col CS8130 e collegare il
tutto ad una seriale invece che alla MB)....  e questo è un punto.
|
| Questa soluzione e' praticamente terminata a livello hardware, infatti
| ho gia' i circuiti adatti (che richiedono solo una modifica per
| ampliare la banda passante).
ne avevamo già un po' parlato... e io sono un po' perplesso...  cmq sistemi
già funzionanti a 9600 bps ci sono già (ti ripeto... vedi flexnet)
|
| Tutto il lavoro sta nella parte software.
hai....  che dolore...   quando mi tiri fuori sti "problemini".... mi viene
un colpo!!!...  secondo tè un lavoro del genere è semplice da
codificare?!?!?...
|
| Innanzitutto questa soluzione puo' funzionare praticamente solo sotto
| Linux, perche' solo li e' possibile scrivere i moduli per il kernel
| senza farsi venire la barba bianca.
mhmmm   spero di imparare ad usare il DDK ...   che con le DirectSound si
fanno MERAVIGLIE!!!!!
|
| Veniamo al dunque.
| Questa soluzione usa una scheda audio controllata a
| cristallo(generalmente una soundblaster) come dispositivo DSP
| e trasmette il segnale su un trasmettitore laser in FM.
Con una bella vecchia SoundBlaster si va' sul sicuro!!!
| Il trasmettitore potrebbe essere quello di Nuova Elettronica, ma
| modificato per portare la banda passante da 10 a 23KHz e la portante
| da 40 a 100KHz.
| Un simile ricetrasmettitore dovrebbe costare sulle 100Klire diodo
| laser incluso.
Qui è il tuo campo!!
|
| E' FM per i soliti motivi: allunga la vita del diodo laser ed e' poco
| sensibile alle turbolenze atmosferiche.
|
| Adesso veniamo alla scheda audio.
| La SB campiona il segnale a 44100Hz e 16bit (facciamo 12bit per la
| SB16) e quindi potenzialmente puo' disporre di una banda molto grande.
| Se le cose fossero cosi' semplici sarebbe fatta... non e' cosi'.
Allora...  Teoricamente se si riuscisse ad andare a 44k1 Hz a 16bit...
(ripeto queta è pura teoria... )  si avrebbero max..   44k1 * 16 bit
705600bps....  questo effettivamente è il bitrate col quale si "alimenta" la
scheda sonora.  Tanti vero??!?..  bene  tornando alla pratica...  la banda
disponibile dai 44k1 campioni al sec.  è (per il T di Shannon)  ridotta a
22050 (ma si parla ancora di teoria...  perchè in questo caso bisognerebbe
avere dei filtri ideali...  quindi in realtà si hanno 20Khz tranquilli.)
... diciamo quindi 20KHz.
|
| Con un SB non possiamo usare una modulazione standard come la FSK:
| al massimo ci potremmo fare appena 19200bps se va bene.
i 9600bps li ho fatti anche sul mio vecchio P100... di più nin zo'
|
| Questo sistema torna utile se possiamo farci piu' di 115Kbps,
| altrimenti tanto vale tenerci il CS8130 che ' piu' economico.
secondo me' il CS8130 o cmql'IrDA è inevitabile .. per un semplice problema
che diro' tra poco.
|
| Ok, cio' che non va bene con la FSK e' che si tratta di una
| modulazione robusta e semplice, ma non molto efficiente.
bhe.. è vero.
|
| Il nostro e' chiaramente un canale limitato in banda: bisogna usare
| quindi una modulazione che ottimizzi la banda.
|
| La disponibilita' di una Sound Blaster ci permette di realizzare cose
| impensabili e prima assolutamente non realizzabili con circuiti
| discreti come quelli dei modem radioamatoriali.
ricorda...  come direbbe il mio docente di F. di Informatica...   tutto ha
un costo.... ha ha ha (si' si'... fa' anche un ghignio malefico quando lo
dice!!!)
|
| Ho progettato per la Sound Blaster uno schema di modulazione ibrido a
| due strati.
| Il primo strato e' una variante della modulazione PAM (Pulse Amplitude
| Modulation) ed e' il vero nucleo di questa tecnologia.
| Il secondo strato e' realizzato in modo trasparente nell' RTX in FM ed
| e' la conversione da PAM ibrida a MFSK (Multiple Frequency Shift
| Keying).
mhmm...  ma la PulseAmplitudeModulation come cacchio la vuoi usare??  mi
piace l'idea dela PAM... ma non ho capito bene cosa intendi
|
| Descriviamo questa PAM ibrida.
| Una simile modulazione non e' proprio una vera PAM, infatti e' un
| qualcosa gestibile solo via DSP.
se lo dici te....
|
| Sostanzialmente abbiamo una portante a 10KHz: ogni *semionda* di
| questa portante ha una ampiezza diversa che codifica il simbolo
| trasmesso.
bhe..  forse ho capito.....  occhio che il sistema così fatto è  MOLTO
SENSIBILE ALLE VARIAZIONI DI AMPIEZZA!!!!  Basta una piccola interferenza
per mandare a puttane tutto!!  Cmq... continua...
| Ho previsto simboli fino a 8 bit , il che significa che noi
| campioniamo a  16bit ogni semionda e ognuna ha 256 ampiezze possibili.
|
Secondo me' discriminare 256 diventa pesante....   sarebbe bello un sistema
che varia dinamicamente i livelli in funzione della qualità della linea...
ma questo è abbastanza complicato!!!
|
| IL che significa che possiamo arrivare fino ad un bit rate di 160Kbps
| con una banda di 20KHz.
Che calcolo hai fatto??
|
| Ora, sarebbe imopossibile realizzare in componenti discreti una cosa
| simile.
Su questo sono daccordissimo!!
| Infatti tutto e' via DSP: all'inizio di ogni pacchetto e' prevista una
| sezione con una portante di ampiezza massima e poi decrescente 16
| livelli per volta.
... tanto per sincronizzarsi...  tipo i due  01111110 dell' HDLC
| In questo modo troviamo i punti di zero-crossing risolvendo un sistema
| trascendente a tre equazioni banalizzato a due e possiamo anche
| normalizzare le ampiezze di picco.
Non ti sto' seguendo!!.. HELP.
 Tutto questo serve a
| autosicronizzare il sistema DSP sulla portante. Ottenuta una prima
| sincronia si effettua un perfezionamento dei dati mediando su piu'
| campioni.
Ok.
| POi inizia la vera trasmissione: ottenuto un campione e la posizione
| temporale del punto di attraversamento dello zero (zero-crossing)
| e' possibile effettura una interpolazione sinusoidale e trovare
| l'ampiezza di picco della semionda.
Ok.. detto in parole semplici si confronta l'onda campione e si capisce che
valore di ampiezza si ha...  quindi si conoscono gli 8 bit codificati
nell'ampiezza.
| Si noti che tra una semionda e l'altra vi e' una discontinuita' di
| primo tipo
che???   dove...  scusa.. ma perchè il limite destro e quello sinistro
dovrebbero essere diversi???  non ti seguo...
 (cmq e' una linea spezzata ma senza salti) su cui si
| concentra la maggiora parte dell'alta frequenza.
mhmm... se Fourier non mi tradisce (nel senso che mi son fatto un progr. per
simulare quello che hai detto...   ma non funge troppo bene quando lo
metterò u npo' a punto potra' essere molto utile per "inventare" nuove
modulazioni.)  le altre frequenze più che altro sono situate intrinsecamente
nel variare delle ampiezze delle varie semionde.... non so' se mi son
spiegato....   e poi un'altra considerazione:  c'è un picco di freq. sui
20Khz che secondo me è eliminabile.....   si utilizza uno stile tipo SSB  si
elimina la freq. dei 20Khz e secondo me' si riesce ad ottimizzare il
tutto...
| Ovviamente un potremo mai campionare questa discontinuita' , eliminata
| dall'anti-aliasing.
NNOOOO  perdi dati...
| Il fatto che localmente la forma d'onda sia sinusoidale, pero' ci
| aiuta, infatti se e' vero che l'antialiasing genera una deformazione
| dell'onda,il fatto di averla resa quasi-sinusoidale ci permette di
| minimizzare l'errore.
mhmmm     forse....
|  Inoltre ricordando che all'inizio avevamo preparato una scala per la
| normalizzazione basandoci su dati reali possiamo essere relativamente
| tranquilli.
|
Questo' si.... pero' il mio dubbio risiede nel fatto che tutta stà roba stia
in "soli" 20Khz....
| Questa modulazione, mi duole dirlo e' realizzata attraverso impulsi
| ideali. Il ricevitore pero' non potra' riceverla come vermanete e' e
| questo genera errori.
a questo ci dovremo abituare!!
| Io penso comunque che sia possibile anche usare impulsi non ideali con
| un fronte di salita finito: e' infatti possibile incorporare i
| suddetti nella forma d'onda e filtrarli realizzando il fintrlo inverso
| al ricevitore.
Penso che questo sia un problema marginale...  tieni presente che una scheda
sonora è abbastanza evoluta.
|
| A proposito, ho idea che un simile schema di modulazione sia usato
| altrove, comunque io penso che non sia affatto malvagio.
Si'... come idea è bella... bisogna simulare il vero occupamento di banda...
vedrò di creare un .Wav con uno stream di campioni di questo tipo.
| A proposito, ovviamente si puo' ridurre il numero dei bit trasmessi:
| potremmo anche andare a 6bit per impulso e ottenere 120Kbps.
| Tutto sta nel ridurre gli errori e nel livello del rumore.
magari lo si fa' anche dinamicamente!!!
|
| A proposito, a 1.5KHz, cioe' con un CB, ad es. si potrebbero  ottenere
| comodamente 19k2 bps.
mhmmm...  ti ripeto....  bisogna vedere sempre la REALE occupazione di
banda.
|
| A, ecco l'ultima cosa:
| matematicamente e' tutto pronto e non e' affatto pesante, c'e' solo da
| metterlo in codice sorgente e scrivere il modulo del Kernel.....
hai più o meno ragione.
|
| In teoria si potrebbero fare distanze molto piu' lunghe, probabilmente
| 10-20Km senza problemi.
|
| Nospam
|
|
BLOCCA TUTTO!!!!!!  Hai detto la portante a 20Khz....  ERRORE...   bisogna
metterla al centro della banda a disposizione!!!  e cioè 10Khz!!!!
(Shannon!!!)
In fine....  ecco il mio dubbio PRINCIPALE....   quanta potenza
computazionale richiede un sistema del genere!??!?   10% del CPU Time?!??!
TROPPO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!     Secondo
me' il gioco non vale la candela....   bisogna vedere...
Ciao
|
--
---
Alberto Gorni
Via E. Da Pozzo 39/15
16133  Genova GE
Italy
E-mail 
san...@tiscalinet.it
Fast E-mail 
san...@mail.omnitel.it
Cell: 
+39 347 5147196
Fax: +39 2 700 351 45

10-20Km senza problemi.
SLURP!
Attendo sviluppi...
Fabrizio

TROPPO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!     Secondo
No, penso che richieda intorno ai 2 MFlops , tanto si tratta solo di
fare delle divisioni e dei confronti.


| wrote:
|
| >effetti nel laser link lo si usa proprio così... ma allora se 2+2 fa' 4
dai
| >pin della scheda madre dovrebbero uscire esattamente le stesse cose che
| >escono dal chip...   quindi le collisioni ey simila sono gestite dal
| Hai ragione: il vantggio del CS8130 e' che possiamo usare la seriale
| senza ataccare roba ai PIN della MB e , credo, senza dover scrivere
| drivers.
Basta impostare l'interfaccia IrDA da BIOS come "Emulazione porta seriale" e
il gioco è fatto!!!   ecco le uscite TX e RX penso Identiche a quelle del
CS8130!!!!
|
cut....
|
| >hai....  che dolore...   quando mi tiri fuori sti "problemini".... mi
viene
| >un colpo!!!...  secondo tè un lavoro del genere è semplice da
| >codificare?!?!?...
| Semplice no di certo. Penso che si possa sfruttare qualcosa che gia'
| gestisce l' AX.25 e cambiare la parte che decidifica la modulazione
| FSK con la nuova modulazione.
mhmmmm la vedo dura... questi tipi di sorgenti sono pieni zeppi di
ottimizzazioni varie (il C è un bastardo in questo senso!!!) e il + delle
volte sono INCOMPRENSIBILI!!!
| Se non altro non si deve scrivere nulla da 0.
in effetti sarebbe bello!!
|
cut...
| >
| >secondo me' il CS8130 o cmql'IrDA è inevitabile .. per un semplice
problema
| >che diro' tra poco.
| Io penso che sia inveitabile in ogni caso: ma sarebbe meglio avere una
| alternativa ragionevole, perche' saldare i suoi microscopici piedini
| non e' il massimo della vita.
bhe.. sono SMD vero???... bisogna  cercare un integrato che facci le stesse
cose in formato DIL oppure bisogna farci un bel master per fotoincisori e
trovare qualcuno con i OO per saldare in SMD!!!
|
| >ricorda...  come direbbe il mio docente di F. di Informatica...   tutto
ha
| >un costo.... ha ha ha (si' si'... fa' anche un ghignio malefico quando lo
| >dice!!!)
| Scrivere il SW e' la parte + difficile, fatto quello il costo dovrebbe
| essere basso. Spero.
Non parlavo di costo monetario... (quello è il meno.... a me scrivere un SW
non costa niant'altro che un po' di tempo, qualche chilo di carta e un po'
di corrente per far funzionare il PC).... ma di costo computazionale...
un bel CS8130 sai a quanti MFlops di potenza di calcolo equivale????    un
bel po'....  pensa solo al fatto che il mio modem (USRobotics Flash 56k
esterno..... er' meyo per linee analogiche) dentro ha un processore a 92Mhz
con una potenza di calcolo di circa 45MIPS (capisco che i  MFlops sono
l'unità di misura delle istruzioni a virgola mobile mentre i MIPS sono più
generici... ma 45MISP non ce li aveva neanche un 386!!!!!!!)
|
| >mhmm...  ma la PulseAmplitudeModulation come cacchio la vuoi usare??  mi
| Ogni semionda ha una ampiezza diversa (e quantizzata). Eventualmente
| possiamo anche fare una onda intera, ma se ho ragione non sara'
| necessario. La PAM normale invece prevede una portante a freq mollto
| piu' alta della frequenza di simbolo, io invece conto di usare una
| frequenza che e' meta' della frequenza di simbolo, o eventualmente
| uguale.
Certo... ora mi ricordo....  hai ragione!
| >| Una simile modulazione non e' proprio una vera PAM, infatti e' un
| >| qualcosa gestibile solo via DSP.
| >
| >se lo dici te....
| Farlo in modo analogico e' impossibile, infatti ogni pacchetto adatta
| dinamicamente i livelli.
|
con componenti discreti è praticamente impossibile!
| >bhe..  forse ho capito.....  occhio che il sistema così fatto è  MOLTO
| >SENSIBILE ALLE VARIAZIONI DI AMPIEZZA!!!!  Basta una piccola interferenza
| >per mandare a puttane tutto!!  Cmq... continua...
| Hai capito bene. Non a caso uso un rtx FM:-) cosi le turbolenze
| atmosferiche non rompono le scatole.
ho capito...
|
| >Secondo me' discriminare 256 diventa pesante....   sarebbe bello un
sistema
| L'h pensato anche io, comunque riducendo il numero dei bit e adattando
| i livelli ad ogni pacchetto dovremmo farcela.
come fa' un normale modem per linea analogica telefonica: in presenza di
rumori rieffettua l'hand shake e stabilizza una nuova velocità!!
|
| >che varia dinamicamente i livelli in funzione della qualità della
linea...
| >ma questo è abbastanza complicato!!!
| Effettivamente e' quello che ho intenzione di fare...
|
| >
| >|
| >| IL che significa che possiamo arrivare fino ad un bit rate di 160Kbps
| >| con una banda di 20KHz.
| >
| >Che calcolo hai fatto??
|
| 8bit per 20000 semionde al secondo.
bhe.. hai ragione....  ma quello che dici te è il limite teorico max...
usando 8 bit... ma hai fatto un errore: se dici di trasmettere 8 bit ogni
semionda... si hanno in totale 8bit x 20000 * 2!!!  cioè 320Kbps!!!!!!  ....
ma io rimando sempre sul fatto che secondo me'... a naso...  il  tutto non
STIA NEI 20KHz!!!!  sarebbe troppo bello!!!
| >
| >... tanto per sincronizzarsi...  tipo i due  01111110 dell' HDLC
|
| Precisamente, e anche per adattare 'dinamicamente' i livelli.
| >
| >| In questo modo troviamo i punti di zero-crossing risolvendo un sistema
| >| trascendente a tre equazioni banalizzato a due e possiamo anche
| >| normalizzare le ampiezze di picco.
| >
| >Non ti sto' seguendo!!.. HELP.
| In breve ci sincronizziamo e e allo stesso tempo normalizziamo i
| livelli, tutto risolvendo un sistema che permette di interpolare
| sinusoidalmente i campioni.
| L'ampiezza di picco che e' uno dei parametri del sistema la si puo'
| stimare dai campioni a parte commettendo un piccolo errore e cosi si
| riduce l'ordine del sistema.
che ordine di sistema verrebbe fuori???  ma poi... se si usano schede sonore
di buona qualità... che sincronizzazioni servono?!?!?!?  se si trasmette a
20KHz 20KHz ci sono e basta... al massimo serve un piccolo handshake per
determinare valore max di picco della semionda...
|
| >
| >Ok.. detto in parole semplici si confronta l'onda campione e si capisce
che
| >valore di ampiezza si ha...  quindi si conoscono gli 8 bit codificati
| >nell'ampiezza.
|
| Certo!
|
| >
| >| Si noti che tra una semionda e l'altra vi e' una discontinuita' di
| >| primo tipo
| Sorry per il numero della discontinuita, pensavo che fosse il primo
| tipo, ma evidentemente era un tipo differente.
mi sembra che sia il 3°.... quelle "eliminabili"... o forse della seconda...
poco importa... quello che importa è che innalzano le armoniche!!!  ed è
quello che a noi interessa contenere!
|
| >
| >che???   dove...  scusa.. ma perchè il limite destro e quello sinistro
| >dovrebbero essere diversi???  non ti seguo...
| Non lo sono, infatti:-(. Sono differenti solo le derivate prime.
| >modulazioni.)  le altre frequenze più che altro sono situate
intrinsecamente
| >nel variare delle ampiezze delle varie semionde.... non so' se mi son
|
| Si
|
| >spiegato....   e poi un'altra considerazione:  c'è un picco di freq. sui
| >20Khz che secondo me è eliminabile.....   si utilizza uno stile tipo SSB
si
| Temo di no. Tra parentesi forse e' meglio non puntare ad elimanare
| picchi di frequenza, non vorrei alterare la forma d'onda.
hai mai visto una FT di un segnale SSB!!!!  ecco.. praticamente un bordello
della madonna!!! .... il ricevitore infatti la rigenera in locale e la somma
al segnale per poterlo ricostruire... ma con un DSP abbastanza evoluto è
teoricamente possibile riconoscere un segnale SSB senza effettuare la
ricostruzione della portante (nella quale non "viaggia" alcuna
informazione!!!!)... dato che l'informazione è TUTTA contenuta in una delle
2 bande.
|
| >Questo' si.... pero' il mio dubbio risiede nel fatto che tutta stà roba
stia
| >in "soli" 20Khz....
|
| Dovrebbe starci se usassimo impulsi non ideali. Oggi rivedo le
| trasformate, pazienta un po'.
come la fai la trasformata?!?!?
|
| >Si'... come idea è bella... bisogna simulare il vero occupamento di
banda...
| >vedrò di creare un .Wav con uno stream di campioni di questo tipo.
| Sarebbe una ottima cosa.:-)
| >BLOCCA TUTTO!!!!!!  Hai detto la portante a 20Khz....  ERRORE...
bisogna
| No, la portate e' a 10KHz, altrimenti avemmo armoniche oltre i 20KHz
| che sarebbero eliminate.
aaaa ecco... allora hai ragione anche sul fatto dei 160KHz....
| >In fine....  ecco il mio dubbio PRINCIPALE....   quanta potenza
| >computazionale richiede un sistema del genere!??!?   10% del CPU
Time?!??!
| >TROPPO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!     Secondo
|
| No, penso che richieda intorno ai 2 MFlops , tanto si tratta solo di
| fare delle divisioni e dei confronti.
si'... forse hai ragione... infondo non deve fare una FFT!!!....


come la fai la trasformata?!?!?
Ci sono delle tecniche adatte per calcolare la trasformata esatta a
mano:-)  comunque io ho gia' a disposizione la trasformata
dell'impulso e penso proprio che usero' il trucco della convoluzione.
Ciao!

 >bhe.. hai ragione....  ma quello che dici te è il limite teorico max...
cut..


| wrote:
| >
| >bhe.. hai ragione....  ma quello che dici te è il limite teorico max...
| >usando 8 bit... ma hai fatto un errore: se dici di trasmettere 8 bit ogni
| >semionda... si hanno in totale 8bit x 20000 * 2!!!  cioè 320Kbps!!!!!!
....
| >ma io rimando sempre sul fatto che secondo me'... a naso...  il  tutto
non
| >STIA NEI 20KHz!!!!  sarebbe troppo bello!!!
|
| no, io intendevo 8bit*10KHz*2   e la banda occupata va dalla base a
| 20KHz.
aaaaa ecco...
|
| >
| >che ordine di sistema verrebbe fuori???  ma poi... se si usano schede
sonore
|
| Terzo ordine all'inizio, secondo ordine (banale) alla fine.
vabbo'...  mi servirebbe un esempio per capirlo..
|
| >di buona qualità... che sincronizzazioni servono?!?!?!?  se si trasmette
a
| Servono per compensare la differenza di fase tra le due schede, la
| trasmittente e la ricevente.
e  hai anche ragione... sorry
|
| >mi sembra che sia il 3°.... quelle "eliminabili"... o forse della
seconda...
| >poco importa... quello che importa è che innalzano le armoniche!!!  ed è
| >quello che a noi interessa contenere!
|
| Precisamente:-)
thank you...
| >hai mai visto una FT di un segnale SSB!!!!  ecco.. praticamente un
bordello
| >della madonna!!! .... il ricevitore infatti la rigenera in locale e la
somma
|
| E' per questo che non ci penso nemmeno ad andare in SSB.
.. ho detto che è "difficile" ma non impossibile...
|
| >al segnale per poterlo ricostruire... ma con un DSP abbastanza evoluto è
| >teoricamente possibile riconoscere un segnale SSB senza effettuare la
| >ricostruzione della portante (nella quale non "viaggia" alcuna
| >informazione!!!!)... dato che l'informazione è TUTTA contenuta in una
delle
| >2 bande.
| Eppure c'e' qualcosa che mi lascia perplesso.
ha ha ... hai visto il PCR1000 della ICOM... ok.. no' di sicuro. (a meno che
tu non ti interessi di ricevitori...)   bene... la SSB la demodula via
DSP... stessa cosa per AM , FM e FM-w!!!!  e il tutto è grande quasi come il
mio modem, e lo si attacca al PC per controllarlo... ... per la cronaca
riceve da 100kHz a 1.3GHz mi sembra...
| Io ho cercato di usare una portante a 10KHz proprio per semplificare
| la demodulazione.
|
ok... ora bisogna vedere se il tutto ci stà veramente nei 20KHz...
| >
| >|
| >| >Questo' si.... pero' il mio dubbio risiede nel fatto che tutta stà
roba
| >stia
| >| >in "soli" 20Khz....
| >|
| >| Dovrebbe starci se usassimo impulsi non ideali. Oggi rivedo le
| >| trasformate, pazienta un po'.
| >
| >come la fai la trasformata?!?!?
| Ci sono delle tecniche adatte per calcolare la trasformata esatta a
| mano:-)
AAAAAAAAAAAAAAAAA!!!!!!!!!!!!!!!!!!!!!!  AIUTOOOOOOOOOOO!!!!  NON CI CREDO!!
A MANO!!!!!
comunque io ho gia' a disposizione la trasformata
| dell'impulso e penso proprio che usero' il trucco della convoluzione.
a parte che non so' come si faccia!!  ma sei PAZZO?!!?  ESISTONO IN GIRO UN
PUTTANAIO DI PROGRAMMI!!!
|
| Ciao!
|
Ciao..
p.s. ti è arrivato il programma in VB che fa' la trasformata??
p.p.s.....  ho trovato un bel sistema real-time di elaborazione sonora...
beccati sto' sito:
http://www.anwida.com
--
---
Alberto Gorni
Via E. Da Pozzo 39/15
16133  Genova GE
Italy
E-mail 
san...@tiscalinet.it
Fast E-mail 
san...@mail.omnitel.it
Cell: 
+39 347 5147196
Fax: +39 2 700 351 45
My Home Page:  
http://web.tiscalinet.it/alberto_g
Il progetto CityLAN:  
http://citylan.floating.net

PUTTANAIO DI PROGRAMMI!!!
Provo anche con Cool Edit per vedere se ho ragione.