sp6ryd pisze:
ojtam ojtam. zgryźliwości i zaczepki mamy już za sobą na tym forum
Faktycznie robiłem we wczesnych latach 90' dzwonek do drzwi, który odgrywał z EEPROM 27256 dźwięk sampla przeniesiony z AMIGI. Astabilny przycisk wyzwalał licznik który adresował EEPROM. Zegar był chyba nawet na NE555. Na wyjściu z EEPROM był przetwornik C/A a'la COVOX - czyli właśnie R/2R.
W tym projekcie EEPROM miałby za małą pojemność i pobierałby za dużo prądu. Przywołałem to tylko po to by przybliżyć prostą zasadę działania.
Chodzi o to że jak już mamy procka (bo jakiś być musi by pozycje GPS nadawać) to odtworzenie za jego pomocą sampla 8k/s nie stanowi zapewne dużego wyzwania.
Tu oczywiście (w tym wątku) mamy bardzo sprytne rozwiązanie bo nawet tego CPU nie potrzeba (player odtwarza w kółko sygnał modulujący nadajnik stale włączony) ale oczywiście na tej samej lince pod balonem będzie jeszcze tracker z sondy który nada pozycję.
Moglibyśmy podejść do SSTV jeszcze inaczej. Czytać prockiem obrazek z pliku i enkodować cały sygnał programowo. ale do tego trzeba by dokładnie poznać kodowanie Scottie-1 wraz z timingiem i generowaniem syg. synchronizacji. Robiłem na Arduino UNO jak dotąd tylko test z prostym trybem SSTV mono 8s generując mozaikę odcieni szarości. Główny problem to zależności czasowe. Nie korzystałem z przerwań i dodanie jednego rozkazu w pętli powodowało rozsynchronizowanie całości. Mimo wszystko jestem przekonany że dla 32 bitowego procka w sondzie RS nie byłoby to zadanie trudne (może ograniczeniem być dostępna pamięć - do zweryfikowania). Muszę znaleźć więcej czasu na STM32. Puki co cieszy każdy balon z Polski puszczany przez kolegów.
sq6ade pisze:
RYDek ale zgryźliwy jesteś Pewnie zwykły przycisk monostabilny przerabiałbyś na bistabilny andrutinem zamiast po bożemu zrobić to np. na cmos4013.
RYDek ale zgryźliwy jesteś
Pewnie zwykły przycisk monostabilny przerabiałbyś na bistabilny andrutinem zamiast po bożemu zrobić to np. na cmos4013. ojtam ojtam. zgryźliwości i zaczepki mamy już za sobą na tym forum
Faktycznie robiłem we wczesnych latach 90' dzwonek do drzwi, który odgrywał z EEPROM 27256 dźwięk sampla przeniesiony z AMIGI. Astabilny przycisk wyzwalał licznik który adresował EEPROM. Zegar był chyba nawet na NE555. Na wyjściu z EEPROM był przetwornik C/A a'la COVOX - czyli właśnie R/2R.
W tym projekcie EEPROM miałby za małą pojemność i pobierałby za dużo prądu. Przywołałem to tylko po to by przybliżyć prostą zasadę działania.
Chodzi o to że jak już mamy procka (bo jakiś być musi by pozycje GPS nadawać) to odtworzenie za jego pomocą sampla 8k/s nie stanowi zapewne dużego wyzwania.
Tu oczywiście (w tym wątku) mamy bardzo sprytne rozwiązanie bo nawet tego CPU nie potrzeba (player odtwarza w kółko sygnał modulujący nadajnik stale włączony) ale oczywiście na tej samej lince pod balonem będzie jeszcze tracker z sondy który nada pozycję.
Moglibyśmy podejść do SSTV jeszcze inaczej. Czytać prockiem obrazek z pliku i enkodować cały sygnał programowo. ale do tego trzeba by dokładnie poznać kodowanie Scottie-1 wraz z timingiem i generowaniem syg. synchronizacji. Robiłem na Arduino UNO jak dotąd tylko test z prostym trybem SSTV mono 8s generując mozaikę odcieni szarości. Główny problem to zależności czasowe. Nie korzystałem z przerwań i dodanie jednego rozkazu w pętli powodowało rozsynchronizowanie całości. Mimo wszystko jestem przekonany że dla 32 bitowego procka w sondzie RS nie byłoby to zadanie trudne (może ograniczeniem być dostępna pamięć - do zweryfikowania). Muszę znaleźć więcej czasu na STM32. Puki co cieszy każdy balon z Polski puszczany przez kolegów.
Wiesz jak to wygenerować z up. Weź no zrób i daj
Projekt przedstawiony przez autora tematu jest dobry bo nie wymaga znajomości programowania. Łączy się kilka klocków "LEGO" i śmiga
Trochę mało ambicji ale wiadomo jak kończą się ambicje ("Pulpfikszyn"
.
"Panta rej" jak mawiał Demokles z Akwirynu
SR6MA w mobilku 145.350 home
SR6MA w mobilku 145.350 home