@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.
(09-05-2012 22:44)SP9RQA napisał(a): [ -> ]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.
(09-05-2012 22:45)SQ6OWH napisał(a): [ -> ]@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.
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.
(09-05-2012 23:00)SP9UOB napisał(a): [ -> ]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.
(09-05-2012 23:00)SP9UOB napisał(a): [ -> ]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,
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ę.
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.
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.
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:
(15-05-2012 10:51)SQ9MDD napisał(a): [ -> ]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:
