On 22-11-2013 17:25, Jarosław Sokołowski wrote:
> Pan John Smith napisał:
>
>>>>>>>>> Synchronizować? Wręcz przeciwnie. Problem ten sam, co w ethernecie.
>>>>>>>> Trochę nie o to mi szło - miałem na myśli, żeby każdemu ustawić trochę
>>>>>>>> inny czas, w którym swoje krzyknie, a potem ewentualnie dać losowo.
>>>>>>> Tylko losowo. To jedynie słuszny kierunek.
>>>>>> "Losowość" sama się zrobi, wystarczy skorzystać z zegara RC w uC.
>>>>>
>>>>> Ale to będzie losowa częstotliwość, a nie losowe odstępy między sesjami.
>>>>
>>>> Przełoży się to na losowe odstępy między paczkami, zgodnie z rozkładem
>>>> normalnym.
>>>
>>> Dwie stacje mogą "wylosować" tę samą częstotliwość a potem pechowo się
>>> zsynchronizować i wzajemnie przekrzykiwać w tym samym momencie.
>>
>> Dokładnie mówiąc, ten sam moment nadawania, bo częstotliwość (kanał)
>> jest z definicji ta sama.
>
> Tak, chodziło mi o częstotliwość (albo inaczej częstość) nadawania
> raportów. Może być w dwóch stacjach taka sama, mogą się przez przypadek
> zsynchrobuzować.

Ręce opadają.


>>>>>> I taniej o jeden element w układzie.
>>>>>
>>>>> O jaki element? Liczby pseudolosowe generuje się programowo. Wystarczy
>>>>> kilka linijek kodu.
>>>>
>>>> Kwarc, jak koniecznie nie muszę, to nie stosuję tego elementu. W tej
>>>> aplikacji, brak kwarcu jako zegara dla uC, jest wręcz pożądany.
>>>
>>> A bez kwarcu to nie można tych kilku linijek dopisać? Nie twierdzę, że
>>> koniecznie trzeba, ani że w praktyce ich brak powoduje częste kłopoty.
>>> Ale kierunek to słuszny, podbudowany teoretycnie.
>>
>> Ale po co pisać, jak projekt tego nie wymaga? Nie wymaga też fontanny
>> i też jej tam nie ma. A tak potrzebna funkcja rozjechania momentów
>> nadawania jest realizowana jako uboczna niedoskonałość zegarów RC.
>
> Fontanna wymaga na przykład doprowadzenia wody, jakiejś pompki itp.
> A tu sprawę załatwia kilka linijek dopisanych od niechcenia.

Tu też.
K.