On Tue, 4 Sep 2012, Artur Maśląg wrote:

> W dniu 2012-09-04 20:43, J.F. pisze:
>> Dnia Tue, 04 Sep 2012 20:02:31 +0200, Artur Maśląg napisał(a):
>>> W dniu 2012-09-04 19:54, J.F. pisze:
>>>>> A to nie jest tak, że "wkodowany" w pamięć nieulotną centralki pilot
>>>>> wysyła
>>>>> serie kodów, która jeśli pasuje do (zaszytego znowu w pamięci
>>>>> nieulotnej)
>>>>> algorytmu odpowiednio reaguje?
>>>>
>>>> Pamietaj ze powinno to dzialac tak, ze jesli ktos odbierze sygnal z
>>>> pilota,
>>>> i pozniej wytransmituje do samochodu, to ten sie nie otworzy.
>>>
>>> No i tak to działa. Dodatkowo nie trzeba pamiętać jakiegoś "ostatniego
>>> kodu".
>>
>> A co trzeba pamietac ? Nic ?
>
> Trzeba pamiętać dane, które pozwolą z przyjętym poziomem ufności
> zaakceptować transmisję jako "naszą" i "zaufaną". W tego typu systemach
> utrata zasilania jest jednym z założeń poprawnego działania systemu,
> więc można to pominąć w dywagacjach. Powtarzanie "odebranego" sygnału
> też nic nie da, ponieważ ma on swój czas "ważności" i powtórne użycie
> zostanie zignorowane.

Jeszcze nam wyjaśnij, w jaki sposób skutecznie wyłączony klucz
(po jednej lub drugiej stronie) mierzy czas i będzie jasność.
Problem w tym, że jeśli klucz i odbiornik muszą mieć swoje zasilanie
awaryjne (nawet mierzone w mikroamperach, bo zegar CMOS o poborze
poniżej mikroampera to nie problem), to jeśli *ono* zawiedzie,
problem powraca.
Czas możesz odzyskać z GPSa.
Ale skoro polemizujesz z pytaniem czy coś trzeba pamiętać,
to mamy problem - ustalenie co zrobić, jeśli "termin ważności"
wziął i minął.

Przy wymogu istnienia "czasu ważności" wszelkie rozważania o tym,
że *nic* nie trzeba pamiętać, niestety biorą w łeb.
Czy Ty masz ma myśli czasowo zależną tablicę danych, np. wartości
losowych, zapisanych po obu stronach lub coś w tym stylu?
(plus pytanie skąd obie strony biorą *wiarygodny* czas, aby
wykluczyć użycie "starego" kodu, GPS w kluczu nie przejdzie,
a oszukanie klucza da wynik jak poprzednio - pytamy go jaki
klucz będzie ważny za dwa dni :>)

pzdr, Gotfryd