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ć.

>>>>> 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.

--
Jarek