sp6ryd pisze:

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.

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.