Dyskryminator FSK dla sygnału 1200/2200 Hz - alternatywy dla alg. Goertzla?

Wed Feb 02, 2011 4:34 pm   

On 30 Sty, 15:01, Verox <antispam_ve...@bijspamera.veroxsystems.com>
wrote:

A bardzo się upierasz przy tym 2200 Hz? Gdyby z tego zrobić 2400 to
znam niewymagający alg dający się zapisać nawet bez mnożenia, ale
bazujący na tym że każdy symbol zawiera całkowita ilość półokresów
(1200/1800 też by pasowało).
WP

Wed Feb 02, 2011 9:38 pm   

On Wed, 2 Feb 2011 06:34:13 -0800 (PST), WP napisał:

Mnie tam wszystko jedno czy 2200 czy 2400, jednak musiałbym przekonać wszystkich
którzy używają Packet-Radio do przestrojenia się o te 200 Hz wyżej
Algo możesz oczywiście opisać


--
#begin 755 signature.exe
[tomek <at> sikornik <dot> net] vy 73! de SP9UOB
Proud to be 100 percent microsoft free. op. Tomek

Thu Feb 03, 2011 5:59 am   

Verox <antispam_verox@bijspamera.veroxsystems.com> wrote:


APRS?

--
gof

Thu Feb 03, 2011 3:32 pm   

On Thu, 3 Feb 2011 03:59:37 +0000 (UTC), Adam Wysocki napisał:

Tak, ogólnie PR


--
#begin 755 signature.exe
[tomek <at> sikornik <dot> net] vy 73! de SP9UOB
Proud to be 100 percent microsoft free. op. Tomek

Fri Feb 04, 2011 2:17 am   

Verox <antispam_verox@bijspamera.veroxsystems.com> wrote:


PR oprócz APRSu jeszcze żyje? :)

Sam stoję przed tym tematem - chcę się uruchomić na APRSie a żaden tracker z
tych, które przejrzałem, nie spełnia moich potrzeb, więc robię swój. Nie chcę
pisać wszystkiego od nowa tylko w miarę możliwości wykorzystać już istniejące
rozwiązania. I też właśnie rozglądam się za wydajnym sposobem wykrywania
częstotliwości, bo liczenie przejść przez zero (tak działa WhereAVR) podobno
średnio się sprawdza.

FOA-Pack wygląda obiecująco, ale nie znalazłem nigdzie kodu źródłowego do tego
trackera, a to dla mnie podstawa - plik .hex do wrzucenia do mikrokontrolera
mnie nie interesuje.

Mój tracker ma mieć moduł Bluetooth (BTM-112) i komunikować się ze mną przez
telefon, na razie mam wizję komunikacji tekstowej przez telefon (Pocket Putty
na Windows Mobile).

sp5gof

--
gof

Fri Feb 04, 2011 2:20 am   

Verox <antispam_verox@bijspamera.veroxsystems.com> wrote:


PR oprócz APRSu jeszcze żyje? :)

Sam stoję przed tym tematem - chcę się uruchomić na APRSie a żaden tracker z
tych, które przejrzałem, nie spełnia moich oczekiwań, więc robię swój. Nie chcę
pisać wszystkiego od nowa tylko w miarę możliwości wykorzystać już istniejące
rozwiązania. I też właśnie rozglądam się za wydajnym sposobem wykrywania
częstotliwości, bo liczenie przejść przez zero (tak działa WhereAVR) podobno
średnio się sprawdza.

FOA-Pack wygląda obiecująco, ale nie znalazłem nigdzie kodu źródłowego do tego
trackera, a to dla mnie podstawa - plik .hex do wrzucenia do mikrokontrolera
mnie nie interesuje.

Mój tracker ma mieć moduł Bluetooth (BTM-112) i komunikować się ze mną przez
telefon, na razie mam wizję komunikacji tekstowej przez terminal (Pocket Putty
na Windows Mobile).

sp5gof

--
gof

Fri Feb 04, 2011 2:21 am   

Verox <antispam_verox@bijspamera.veroxsystems.com> wrote:


PR oprócz APRSu jeszcze żyje? :)

Sam stoję przed tym tematem - chcę się uruchomić na APRSie a żaden tracker z
tych, które przejrzałem, nie spełnia moich oczekiwań, więc robię swój. Nie chcę
pisać wszystkiego od nowa tylko w miarę możliwości wykorzystać już istniejące
rozwiązania. I też właśnie rozglądam się za wydajnym sposobem wykrywania
częstotliwości, bo liczenie przejść przez zero (tak działa WhereAVR) jak sam
zauważyłeś w realnym środowisku średnio się sprawdza.

FOA-Pack wygląda obiecująco, ale nie znalazłem nigdzie kodu źródłowego do tego
trackera, a to dla mnie podstawa - plik .hex do wrzucenia do mikrokontrolera
mnie nie interesuje.

Mój tracker ma mieć moduł Bluetooth (BTM-112) i komunikować się ze mną przez
telefon, na razie mam wizję komunikacji tekstowej przez terminal (Pocket Putty
na Windows Mobile).

sp5gof

--
gof

Fri Feb 04, 2011 1:55 pm   

On Fri, 4 Feb 2011 12:41:02 +0000 (UTC), Verox wrote:

Beda strzelac do takich :-)


No wlasnie - przeciez jest chyba do tego troche gotowego
oprogramowania, nie mozna podejrzec ?

J.

Fri Feb 04, 2011 2:41 pm   

On Fri, 4 Feb 2011 00:21:41 +0000 (UTC), Adam Wysocki napisał:

Chyba nie, ale warto mieć możliwość postawienia węzła jak
ktoś wyłączy w Polsce Internet ;-)


Jak napiszesz od nowa to rozwiążesz kilka problemów i zrozumiesz
dlaczego tak to działa. Głównie dlatego się za to zabrałem.
Jak już będe miał działający modem w sofcie - to pokusze się o doklejenie do
tego dsPIC'a ethernetu i spróbuje zrobić igate na 2 scalakach :-)


Ciekawy pomysł :-)

--
#begin 755 signature.exe
[tomek <at> sikornik <dot> net] vy 73! de SP9UOB
Proud to be 100 percent microsoft free. op. Tomek

Fri Feb 04, 2011 3:02 pm   

On Fri, 04 Feb 2011 13:55:45 +0100, J.F napisał:

;-)


Większość rozwiązań na uC jest zamkniętoźródłowe.
Podglądałem kilka rozwiązań już - ale na zabawe mam czas tylko w weekendy.
W zeszły weekend doszedłem do wniosku że goertzel reaguje zbyt wolno, za
to mnożenie i opóźnienie wygląda obiecująco. Muszę się tylko nauczyć
projektowania filtrów FIR i ich implementacji.


--
#begin 755 signature.exe
[tomek <at> sikornik <dot> net] vy 73! de SP9UOB
Proud to be 100 percent microsoft free. op. Tomek

Sun Feb 06, 2011 8:48 am   

Verox wrote:


ja bym na twoim miejscu jeszcze przemyslal - filtry i limiter mozna zrobic
analogowo - bedzie szybsze i bedzie pobierac mniej pradu niz procesor...
nie mowiac o zakresie dynamiki ...


--

Mon Feb 07, 2011 6:02 pm   

On 4 Lut, 14:02, Verox <antispam_ve...@bijspamera.veroxsystems.com>
wrote:

Teoretycznie najlepszą detekcję by dawało porównywanie ostatnich
kilkunastu próbek z oczekiwanym kształtem sybmolu dla 0 i 1 (czyli
cały okres 1200 i 1.8 okresu 2200). Porównywanie tu jest policzeniem
korelacji. Gorzej, że symbol 2200 nie zawiera całkowitej ilości
półokresów, tylko ułamek, więc wstawienie takiego symbolu w strumień
zmienia fazę następnych, zatem i ich spodziewany kształt. Byłoby dużo
łatwiej z 1200/1800 lub 1200/2400, bo wtedy każda jedynka czy zero
wygląda tak samo, ew. jest zanegowane. I z korelacji by można
zrezygnować, i synchronizacja rząd wielkości prostsza, same zalety,
ale niestety nie tu:)

Jeśli masz na tyle mocy procka żeby FIR zrobić, to można tak:
Strumień wejściowy na FIR o takiej długości, jak długość symbolu
(dłuższy sprawi, że sąsiednie symbole będą wpływały na siebie, efekt
niemile widziany). FIR ma być taki, żeby przepuszczał do 1200 a
wycinał od 2200. Np. taki (dla 16 kHz):
-0.0523 -0.0256 -0.0050 0.0376 0.0959 0.1559 0.2012 0.2180 i dalej
symetrycznie 0.2012 0.1559...
Na jego wyjściu będzie duży sinus dla 1200 i jakieś śmieci przy 2200.
Tylko że nigdy nie wiadomo w jaką fazę 1200 trafimy, więc ten jeden
okres 1200 może dawać szczyty za każdym razem w różnych miejscach..
Czasem to będzie jeden dodatni i jeden ujemny, czasem jeden ujemny i
dwa słabsze dodatnie, a typowo coś pomiędzy:) Można zliczać symbole
2200 i sobie przewidywać fazę. Ale to dla ambitnych. A można też
wyrównać tego sinusa to czegoś w miarę płaskiego. Gdyby był sygnał
kwadraturowy, to łatwo sobie amplitudę wyliczyć z sumy kwadratów. Ale
że nie ma, to go sobie można zrobić przez opóźnienie o ćwierć okresu
(tak jakby z sinusa zrobić cosinus), i wychodzi amplituda (pierwiastka
nie lubimy):
y[n] = x[n]^2 + y[n-ćwierć okresu]^2
x to wyjście z FIRa. y to już jest sygnał trzymający się wysoko przy
1200 i nisko przy 2200. Do detekcji całkiem się nadaje.

Oddzielny temat to synchronizacja. Do tego przydaje się wiedza o
protokole. Typowo powinna być preambuła, pozwalająca na znalezienie
momentów gdy jeden symbol się kończy a następny zaczyna. Np. histogram
ze zmian tego wyżej wyliczonego sygnału może to podpowiedzieć.
Próbkowanie będące wielokrotnością 1200 też nieco ułatwi. Przy dobrej
synchronizacji można też CPU zaoszczędzić i liczyć wszystko nie co
próbkę, ale raz na symbol.

WP

Mon Feb 07, 2011 11:42 pm   

Verox wrote:


jeszcze jeden pomysl mi przyszedl do glowy :
http://en.wikipedia.org/wiki/Quadrature_mirror_filter
z tym ze moja znajomosc matematyki nie umozliwia mi stwierdzenie czy taki
filtr sie 'nada' (chociaz mysle ze w przeciwienstwie do Groetzla -
wprowadzalby tylko pewne opoznienie, a przy PR/APRS to nieistotne, bo
transmisja jest half-duplexowa) .

idea bylaby tu podobna do uzycia zero-crossing, tzn. dzielimy sygnal na 2
czesci , mniejsze niz 1700 i wieksze niz 1700.

zaleta nad 0 crossing taka, ze nawet rozpoznajac 'bity' na podst. prostej
sredniej z kazdych pasm (czyli albo mamy 'wiecej dolu' albo 'wiecej gory')
mozna wprowadzac prosta 'redukcje zaklocen' - np. malo dokladnym (a co za
tym idzie szybkim) Groetzlem badac 'dol' i 'gore' _poza_ interesujacym nas
pasem - dzieki czemu uzyskamy srednia 'zaklocen' poza interesujacym
prazkiem, i te srednia zwyczajnie odejmujemy przy ostatecznej decyzji od
kazdej ze skladowych. moze dzialac zarowno 'krotkoterminowo' (redukcja
szumow) jak i dlugo (korekcja np. charakterystyki czestotliwosci)

dodatkowa zaleta ze juz po pierwszym 'podziale' uzyskujemy dwa rownolegle
strumienie, ktore mozemy rownolegle przetwarzac - no ale to jedynie jesli
uzywamy jakiegos dsp/fpga/wielordzeniowej architektury , chociaz od biedy
mozna np. uzyc jednego szybkiego mikrokontrolera 'rozdzielajacego' pasma, a
nastepnie np. dwoch dodatkowych , pracujacych rownolegle - analizujacych
kazde z osobna (lub nawet dwoch drabinek DAC i komparatora, ew. analogowych
filtrow)


--