Nowy pomysł związany z APRS-em

[SQ6OWH]

@SP9UOB: pomysł mi się podoba, pytanie, czy jestem w stanie napisać/skompilować/zaprogramować układ pod Linuksem (albo pesymistycznie - ładnie się uśmiechnąć, dostać/kupić binarkę, po czym ustawić fusebity czy co tam PICe mają do konfiguracji i wgrać gotowy "firmware")?

@SP9RQA: duże, płytka z AVT ma wymiary mniejsze od pudełka zapałek, jedyny problem, to rzeźba w SMD - w końcu opanowałem lutowanie SMD "dmuchawką"

Zaletą rozwiązania KI4MCW jest sensowny poziom dekodowanych ramek przy stosunkowo małym koszcie, otwartych źródłach i możliwości dłubania w źródłach pod większością współczesnych systemów operacyjnych. Lubię AVR i to mi odpowiada - ale to kwestia gustu i przyzwyczajeń.
Idąc krok dalej - stos AX25 jest w bibliotekach BeRTos'a - napisanych w C i OIDP dostępnych na zasadach GPL. Można go przerobić.
Podobnie z KISS-TNC KI4MCW - mamy źródła (oparte na... tutorialu BeRTos'a), sam autor był chętny do współpracy (korespondowałem chcąc przenosić KISS-TNC na "dużą" ATmegę by zrobić urządzenie typu "all-in-one"). Obecnie sygnał AF jest demodulowany, AX25 rozpakowywany do wewnętrznej reprezentacji po czym pakowany w ramki KISS i wysyłany na serial. Tą ostatnią część można dowolnie sobie przepisać.

Z drugiej strony - jeśli będzie ustalony interfejs, myślę, że nie stoi nic na przeszkodzie by istniały równolegle moduły nawet dla tej samej modulacji, ale uwzględniające różne możliwości warsztatowe i przyzwyczajenia potencjalnego budowniczego.

[SP9UOB]

No tak, ale sam wiesz ze dsPIC do tanich nie należy, a w tym co go zastosowałeś w projekcie już się nic więcej nie zmieści, choć procesor sie tam raczej nudzi, więc trzeba by zastosować większego dsPIC'a, a co za tym idzie jeszcze droższego.

Na własne potrzeby można mieć gratisowo ;-)

A co do miejsca w kostce - to zastosowanie go tylko i wyłącznie jako stosu AX25 to krok wstecz i odchudzenie kodu.

Co do ceny: DSPIC33FJ128GPP w TME w pdipie kosztuje 20 pln. Ma 16 kilo ramu i od wuja Flasha. Przy samplowaniu 156 kHz i cyfrowych filtrach zamiast max'a mam jeszcze lepszą skuteczność :-)) Atmega128 z tego co widze kosztuje złotych 22 ;-)

Pozostaje jeszcze kwestia programatora, dsPIC'e to jednak mało popularne kostki i wymagają drogich/skomplikowanych programatorów.

---

@SP9UOB: pomysł mi się podoba, pytanie, czy jestem w stanie napisać/skompilować/zaprogramować układ pod Linuksem (albo pesymistycznie - ładnie się uśmiechnąć, dostać/kupić binarkę, po czym ustawić fusebity czy co tam PICe mają do konfiguracji i wgrać gotowy "firmware")?

Powiem tak, cały development robie na linuxie - nie mam windowsa w domu.
Binarki dostępne są na stronie projektu.

Jak uporam się z moim balonowym projektem (czas goni) to będzie równiez bootloader, który umożliwi programowanie kostki via port szeregowy.

[SP5FCS]

Warto rozważyć możliwości nowej rodziny Atmeli Xmega. Procesory pracują z zegarem 32Mhz, bez problemu można je przetaktować na 54Mhz, dwa 12 bitowe przetworniki ADC o szybkości 1 Msampli każdy, dwa przetworniki 12 bitowe DAC, 5 portów szeregowych, RAM (4...16kb) flash (32...392k). Koszt Xmega32 ok. 15zł, Xmega128 ok 35zł. Przetworniki ADC oraz DAC mogą pracować poprzez DMA bez udziału procesora. Przy szybkości 50 MIPS i szybkim ADC+DAC nie powinno być problemu z realizacją takiego projektu.

[SQ6OWH]

Powiem tak, cały development robie na linuxie - nie mam windowsa w domu.
Binarki dostępne są na stronie projektu.

A tak w "bardzo trzech" słowach - jaki język programowania, może nazwa środowiska, ew. zasady dostępności (ale to już sobie do-googlam mając punkt zaczepienia)? Z góry dzięki.

[SP9UOB]

Powiem tak, cały development robie na linuxie - nie mam windowsa w domu.
Binarki dostępne są na stronie projektu.

A tak w "bardzo trzech" słowach - jaki język programowania, może nazwa środowiska, ew. zasady dostępności (ale to już sobie do-googlam mając punkt zaczepienia)? Z góry dzięki.

Rdzeń DSP - Assembler, po pierwsze że szybko, a po drugie C nie ma składni dla DSP, a sprzętowe mechanizmy DSP (pętle sprzętowe, operacje MAC) są po prostu przecudne. Suma kwadratów dwóch wartośći z pobraniem danych zajmuje... 5 taktów zegara :-)

Reszta: C bo wygodniej.

Środowisko: MplabX Darmowe. Kompilatory mają ograniczenia w optymalizacji, ale nie przeszkadza,

[SQ9MDD]

Widzę że tematów do niedzielnej dyskusji będzie sporo i dobrze.
Ja bym chciał by było to jasno powiedziane:

Projekt będzie w 100% otwarty, nie dopuszczę do wrzucenia nawet części "black boxa" do środka.
Projekt musi być tani i powtarzalny, czy też do powtórzenia przez niemalże każdego krótkofalowca.
Projekt ma stanowić bazę do rozwoju kolejnych projektów jako część modemowa.
Projekt ma udostępniać czysty protokół APRS po stronie interfejsu rs/usb/bluetoth.

Pozdrawiam i do zobaczenia (i usłyszenia) w niedzielę.

[SP3SWJ]

Kiedyś mnie ten temat interesował...

Wrzuce kilka linków... jak sie przydadza to fajnie... jak nie ;-) ...

https://code.google.com/p/xmega-qrp/sour...svn22&r=22

http://www.ti.com/lit/an/slaa037/slaa037.pdf
http://www.atmel.com/Images/doc9113.pdf
http://www.avrfreaks.net/modules/FreaksF...DN_027.pdf


:-) tylko nie naruszcie czyjegos patentu :-) http://www.faqs.org/patents/app/20090168857#b


i to :-) TriTone Modem II - Full-duplex (ATmega48)

http://www.vfx.hu/proj/fskmodem/fskmodem_eng.html

żródła ASM :-)

---

kolejny mo-dem ... i źródła
http://www.qsl.net/lz0icp/afsk1200.htm

[SQ6OXK]

Tomku, Twój projekt znam, jest Ciekawy. Sam tworze, różne próby APRS-owego sprzętu i mam pewne pomysły. Przy dekodowaniu korzystam niestety z TCM-a, albo obieram się już na gotowych rozwiązaniach, dających KISS-ową ramkę po RS-ie. Szybki przetwarzanie sygnału z przetwornica AC jak na razie nie jest do przeskoczenia i projekty staja sie nie atrakcyjne.

Od pewnego czasu chcę jednak poprosić Ciebie abyś ciut szarzej opisał mi algorytm dekodowanie ramek i miałem w tej sprawie napisać do Ciebie. Myślę jednak, że jest to dobre miejsce i chwila do zaprezentowania nam przytoczony na Twojej stronie algorytm Thomasa HB9JNX. Wygląda na stosunkowo prostu, szybki i do zaimplementowania w C. Tekst jest jednak po Niemiecku i trudno do końca mi go zrozumieć, na pewno Twoje doświadczenie i wiedzą na ten temat była by bardzo pomocna. Myślę że szarszy opis tego zagadnienie pozwoli pchnął by moje projekty oraz innych kolegów daleko do przody.

[SQ9MDD]

W skrócie najwięcej chyba zależy od algorytmu dekodowania AFSK.
Dzisiaj o 15-tej na politechnice będzie spotkanie zapraszam na TeamSpeak chętnych do dyskusji.

Informacja:
http://sp-hm.pl/thread-1333.html

UPDATE 15.05.2012

Na spotkaniu omówiliśmy najważniejsze kwestie związane z budową modemu. I przeprowadziliśmy testy algorytmu nadającego ramki.
W tej chwili mamy kilka osób w zespole które wyraźnie zadeklarowały chęć pomocy i część pracy została już rozdana.
Myślę że najrozsądniej będzie że w chwili obecnej skupimy się na doprowadzeniu do "wyprodukowania" stabilnego rozwiązania w wersji pierwszej, tak by zbadać praktycznie możliwości przyjętych założeń. Fazą następną będzie dyskusja nad użytymi algorytmami, sposobami dekodowania i kodowania sygnału, a następnie zaproponowanie sensownej ścieżki rozwoju naszego projektu.
Idea jest taka by zespół podczas pracy nad projektem, nabył nowych umiejętności rozwinął swoją wiedzę i doświadczenie. Jednocześnie na starcie nie chcemy stawiać poprzeczki zbyt wysoko by projekt nie spowodował zniechęcenia wśród uczestników.

Poniżej video z pierwszego testu naszego projektu:

[SP9RQA]

W skrócie najwięcej chyba zależy od algorytmu dekodowania AFSK.

(...)
Fazą następną będzie dyskusja nad użytymi algorytmami, sposobami dekodowania i kodowania sygnału, a następnie zaproponowanie sensownej ścieżki rozwoju naszego projektu.
(...)

Myslę, że dobrym punktem odniesienia bedzie modem Tomka. Na swojej stronie pisze, że zdekodował 900 ramek
z płytki testowej CD:

http://sp9uob.verox.pl/aprs_WA8LMF_test.wav

kolejny modem zaproponowany wyniki ma zebrane w tabelce:

http://sites.google.com/site/ki4mcw/Home/arduino-tnc

Myślę, ze jeśli nasz modem zdekoduje poniżej 700 pakietów to trzeba szukać innego rozwiązania... algorytmu.