SSTV do balonu krótkofalrskiego |
sq6ade pisze: RYDek ale zgryźliwy jesteś ![]() ![]() 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. |