Nem az idővel van baj, hanem a dátummal, nem mindegy a sorrend. Honnan tudod mikor kezdődik a dst ? 28 évente periodikus, a matrixos függvény is azt számolgatja. Az órádban a helyi időt +- 13 órával lehet eltolni, ha minden percben ki akarod iratni egyszer a dátumot nem elég a hozzádok egyet a végén, mert már 12órával előtte is lehet más dátum, mindent külön ki kell számítani. De ha ezt nem használod (4digit), akkor valóban egyszerű. Esetleg erre is van egy kész könyvtár, ami stikában belerak még ezer sort a hexbe... ( A táblázat jól megy, kb 3 sort tesz bele a progiba, nem kell kilóméteres longokkal számolni.)

Továbbra sem értem, miért jó a nem-multiplex?
Ez valami trendi izé?

A nyári időszámítás március utolsó vasárnapján kezdődik, és október utolsó vasárnapjáig tart. (Minden évben).
Nyári kezdete: vasárnap hajnalban 2:00 órakor 3:00 órára kell előreállítani az órát
Téli kezdete: vasárnap hajnalban 3:00 órakor 2:00 órára kell visszaállítani az órát.

Azt hiszem kezd parttalanná válni az eszmecsere. Adott a UTC idő, a GPS által adott dátum. A kontroller honnan tudja, mikor van nyári időszámítás? Konkrét algoritmusokról beszélünk. (Jelenleg nincs benne DCF, RTC, NTP, stb. nem olvas wikipédiát és nem hallgat rádiót az óra.)

Ez a wikipediaolvasás nem rossz. Ezen elgondolkozom.

Elég a GPS által szolgáltatott dátum és idő (ami ugyebár UTC).
Illetve van még egy kis "csalás" a dologban, mert ahhoz, hogy tudd melyik az utolsó vasárnap márciusban, illetve októberben, ahhoz kell egy segédtáblából számoló függvény (ami kiszámolja mindig, hogy milyen nap van ("day of week").
De ezekkel már tudni fogja a PIC hogy mizu van.
Szóval fogod a dátumot, felbontod évre, hónapra, napra, és meghívsz egy függvényt, ami visszaad egy számot mondjuk 0..6-ig (0=hétfő, 6=vasárnap, de általában 0=szombat és így tovább..).
Itt van egy pár megoldás: Bővebben: Link. De biztosan le van írva valahol egyszerűbben is.
Még annyi trükk kell, hogy meg kell határoznod, hogy az utolsó vasárnap-e, azaz hogy ha a naphoz hozzáadsz 7-et, akkor az eredmény nagyobb-e mint 31 (ha igen, akkor az uccsó vasárnap van márciusban), illetve azt is nézni kell, hogy "elhagytuk"-e ezt a dátumot.
Ezek után, még azt is meg kell állapítanod, hogy az idő (amit szintén a GPS-től kapsz) >= 02:00:00-nál.
Ugyanez az analógia érvényes az október utolsó vasárnapjára. Szóval ha itt a kapott dátum&idő a két pont (március utolsó vasárnap és október utolsó vasárnap) között van, akkor a megjelenített időnek 2 órával többnek kell lennie az UTC időtől (+1 az időzóna +1 a DST), egyébként csak 1-el (időzóna). Ezt én most hirtelen úgy oldanám meg, hogy a GPS UTC időt ugye felbontom évre, hónapra, napra, órára, és az órához hozzáadok kettőt (vagy egyet, ha nincs DST). Ha ezzel nagyobb mint 23, akkor növelem a napokat, és hopp, itt jön be egy kis nehézség, mert nem minden hónap ugyanannyi nap, plusz számolni kell a szökőévet is...
Szóval meg lehet oldani, bár nem egyszerű. Lehet itt már létjogosultsága lenne egy RTC-nek, az megcsinálja helyettünk ezt a sok számolást (illetve hát ugye hardveresen úgy van kialakítva...).
Szerk.: na remélem nem potyára írtam le ezt a sok okosságot, és valaki legalább belájkolja.

Nem én leszek, aki ezt belájkolja. Köszi, hogy leírtad, amiről HP41C-vel és Bakmannal napok óta beszélünk. Bizonyára elkerülte a figyelmedet, hogy több megoldást és algoritmust is felhoztunk erre a problémára, köztük gyári megoldást, interneten fellelhető algoritmusokat és saját ötletet is, amit még nem láttunk kódolva. Ebben a fázisban az alap kiinduló problémát felvetni és rácsodálkozni nem igazán viszi előre a témát. Esetleg visszaolvashattál volna egy pár hozzászólással...
Az viszont bizonyos, hogy a dcf vagy az rtc áramkör segítene ezen a problémán, de most a megjelent óra szoftveres okosításáról van szó nem teljesen más kapcsolás kidolgozásáról.
Érdekességként anno készült olyan óra, amely a Kossuth rádió füttyjelére nullázta magát éjfélkor így biztosítva a pontosságát, tehát amit írtam az sem volt vicc teljesen.

Valóban, nem egészen néztem meg minden előzményt, ezért elnézést kérek.
Márpedig ha csak egy GPS-ed van a külvilág felé, akkor más lehetőség nem nagyon van. Szerintem.
"Szerk2.: az átszámolásra esetleg van egy jobb megoldás. Átalakítod az időt Unix-idővé, hozzáadsz 7200-at (ha nincs DST, csak 3600-at), majd visszaalakítod. Na remélem ez még nem volt."

Ok. Ne kímélj. A táblázatos módszert azért javasoltam, mert a DST országonként más szabályok szerint került bevezetésre így a kereső string cseréjével más helyekre, időzónára és országra is jó lehetne az algoritmus, akár úgy is, hogy a kezdet és vég két hónapját is beleírom az első két karakterbe.

Írtam egy moderálási kérelmet közben, mert nem engedte már módosítani a hozzászólást, szóval azt várjuk meg.

Én ilyesmire gondoltam:
y=y10*10+y1-1
n=y+(y/4)
ha (mo10*10+mo1)=1,2,3,4,5,6,7,8,9,10,11,12 akkor n=n+0,3,3,6,1,4,6,2,5,10,3,5+ (d10*10)+d1
ha (y10*10+y1) MOD 4=0 és (mo10*10+mo1)>=3 akkor n=n-1
dow=(n MOD 7)+1

Hát, ha kipróbáltad és működik, akkor simán jó.
Nade közben nem írták át a modik még a hsz-t, szóval leírom, hogyan lehetne még megoldani az időállítást (miután megállapítottuk, hogy DST van vagy sem). Szóval fogod a dátumot & időt, és átkonvertálod Unix időbe, majd hozzáadsz 7200-at (illetve ha nincs DST, akkor csak 3600-at), majd visszakonvertálod. Ehhez össze kell guglizni ezt a két függvényt, de szerintem elég elegáns megoldás.

Igen, az a JDN pepitában, de csak 1970-től ketyeg ( igaz másodpercenként és nem naponként...)

Ha az ember allergiás az elektroszmogra, akkor nyerő, esetleg valami mást akar csináltatni a kontrollerrel, és nincs rá idő ( tudom itt nem) akkor is nyerő. Az alkatrészek számát is lehet csökkenteni ily módon. Kezdő programozónak is egyszerűbb a feladat.....

Maradtam az eredeti óra tervhez az európai időzónákra egy egyszerű dst dátum számításnál az alábbiak szerint:
dstkezdete = 31-((INT((5*B2)/4)+4) MOD 7)
dstvége= 31-((INT((5*B2)/4)+1) MOD 7)
Így nem kell a hét napja és a többi időzónában sincs is sok értelme, mert ott nem március és október hónapban változik és nem az UTC szerinti hajnali egy óra a kezdete és a vége. Az időzóna beállítás részt le fogom korlátozni 0-3 órára, vagy kap egy menüpontot az európai dst ki/be kapcsolására.
( A hatdigites változatomban JDN-nel átszámoltam a dátumot így az a két függvény a JDN (JDN MOD 7 a hét napját adja) és a INVJDN megadja a hét napját és a helyi időben kijelzett dátumot az UTC-s dátumhoz képest növelve (illetve csökkentve, ha az időzóna negatív), így minden percben ki tudom íratni a dátumot.)

Lemaradt: B2 az év pl. 2016 , y10,y1 az év tizese és egyese pl y10=1,y1=6, mo10,mo1 hónap tizese és egyese, d10,d1 nap tizese és egyese. A Gy,Gm,Gd a Gergely naptár szerinti év,hó és nap.

A cikkben szereplő kapcsolási rajzon nehezen lehet eligazodni. Az U2 (PIC) és az U3;U4;U5;U6 ULN IC-k kapcsolata. Nincs semmi infó, hogy ezek hogyan kapcsolódnak, mi mihez. A NYÁKon vissza lehet keresni, de a kapcsolás így nem igazán jó. A közös kék jelölés nagyon jó alkalmazás, de ilyenkor jelölni kell az IC-k egymás kapcsolatát is.

Parancsolj: Bővebben: Link.

Igen, ezt megtaláltam én is. Köszönöm A kapcsolási rajzról hiányzik. Nem lehetne ezt a kapcsolási rajzra írni? Az A6;E0;D7;B3; ez ugye RA6; RE0; RD7; RB3; A nyákrajzból ez nem derül ki sajnos. Nem kötekedni akarok, tényleg. A legteljesebb jóindulattal és segítő szándékkal írom.

Majd legközelebb (annó eszembe sem jutott), ez már marad így, ahogy van.

Hello!

Már régen volt hozzáazólás, de gondolom még olvasod.
Írtad, hogy pincében is veszed a GPS jelet. Melyik GPS-modult használod?

Azt, amelyik a cikkben is szerepel, nagy, négyzet alakú, különálló antenna. U-blox neo 6M. Van fele ekkora antennával (nem teszteltem) és olyan változat is, ahol minden egy panelen van (U-Blox Neo 6M_2). Az utóbbi, egy paneles változat gyengébben teljesít ugyanazon körülmények között. Szabadban jó lehet, pláne azért, mert az 1 Hz-es szinkronjel is megtalálható a csatlakozón, de itthon a szobában (nemhogy a pincében) nem tudott ráállni a műholdakra, miközben a korábbi variáns vígan működött.

Nem tudtam, hogy cikkl is van.
Köszönöm.

Üdv Fórumozók!

Én elolvastam a cikket letöltöttem a mellékelt csatolmányt, kicsomagoltam de valamiért nem találok benne forráskódot. Vagy csak nem tudom mit is kellene találnom. Vannak képek, pdf-ek, megvan a hex fájl is meg van 2 db .ai kiterjesztés ami talán nyákterv és van egy .fcf amit nem tudok megnyitni mert nem tudom milyen program kellene hozzá. A google szerint a Final draft nyitja meg de ha megnyitom vele csak egy sornyi krix krax jön elő. Valaki megtehetné hogy felhomályosít erről a dologról.

Flowcode 5 fájl. Flowcode 5 vagy frissebb nyitja. .ai: Adobe Illustrator.

Köszönöm a gyors választ! Letöltöttem, sikerült megnyitni. Bár sajnos sokat nem értem el vele. Sajnos nagyon kezdő vagyok még a pikkek terén így még csak mikro C-ben programozgattam, kisebb nagyobb sikerrel egy egy kisebb programot. Találtam a programban fordítás opciót C-be de az sem teljesen olyan mint a mikro C.

Sajnos a fele akkora gyengébb, nem biztosít annyira jó vételt, mint a cikkben megjelent NEO 6.

Ennyivel is okosabbak lettünk, köszi!

Szia, a kisebb antennájú vevő valóban gyengébb, de nem vészesen. Nekem a GPS vételre átalakított iv-11-es órámban üzemel. Itt a tetőtérben teljesen megfelelő. Amiben elmarad, az a hideg indulás ideje.

Üdv!
Kicsit másként szeretnék GPS-es órát építeni. Az óra cmos áramkörökből állna, erről nem vagyok hajlandó most lemondani. Az elméleti terv az lenne, hogy GPS modul csak az 1 Hz-es órajelet szolgáltatná a számlálóknak. A fő kérdés az lenne, hogy van-e olyan modul, aminek van 1Hz-s vagy valamilyen nagyobb, de fix frekvenciájú kimenete? Elvileg így sokkal pontosabb lenne az óra, persze beállítani manuálisan kéne. Nézelődtem, de nem tudtam eldönteni, hogy lehetne-e ezeket ilyen módon használni. Tanácstalan vagyok.
A válaszokat előre is köszi.