#programista15k

@Fen patrząc na jakosc, zbyt duzo

@MostlyRenegade no cóż, jak używałem zmiennej jako flag to używałem normalnej zmiennej a nie typu enumeracyjnego. Można np też użyć struktury z polem bitowym. Jest sporo alternatyw i moim zdaniem używanie enuma w ten sposób nie jest najlepszym rozwiązaniem

@ZohanTSW użycie enuma ma tę zaletę, że masz od razu ograniczenie zakresu i nie musisz posługiwać się magicznymi liczbami.
O UB też nie ma się co martwić, bo pod spodem enuma i tak masz inta. Konwersja jest więc bezproblemowa. Co najwyżej poleci exception jeśli będziesz próbował podstawić pod enuma wartość spoza zakresu. A to jest nawet lepsze niż podstawienie wartości spoza zakresu pod zwykłego inta, bo jak operujesz intem, to program nawet nie wie, że jest poza zakresem i operuje na śmieciach.

@MostlyRenegade czekaj czekaj

użycie enuma ma tę zaletę, że masz od razu ograniczenie zakresu

jak operujesz intem, to program nawet nie wie, że jest poza zakresem

No czegoś tu nie rozumiem. Nie widzę tego zabezpieczenia w enumie. To prawda, że zachowuje się jak int. Do bólu. Tutaj program również nie wie, że jest poza zakresem. Może jest jakaś przełączka kompilatora, nie wiem 😛

https://godbolt.org/z/EK8Eh9jvj

Nie neguję tego, że rozwiązanie widocznie jest znane i stare jak świat, ale nie zmienia to faktu, że dziś jest nieeleganckie. Według mnie o niebo lepiej jest używać struktur z polami bitowymi bo przynajmniej nie łamią tej jednej reguły xd

Compiler Explorer - C++ (x86-64 gcc 15.1)enum class myEnum { A = 0, B = 1, }; int main () { myEnum x; try { x = static_cast(2137); } catch (...) { std::coutGodbolt

@ZohanTSW w przypadku flag pilnowanie zakresu nawet nie ma sensu, bo i tak testujesz konkretne flagi. Aczkolwiek lepiej jest użyć dedykowanych operatorów niż bezmyślnie dodawać inty, a potem testować maskami.

Nie wiem, jak to dokładnie wygląda w c++, ale w c# do flag najlepiej właśnie stosować enumy, bo masz do nich gotowe operatory i kompilator wie, że chodzi o zbiór wielu stanów, a nie tylko jednego.

@MostlyRenegade w c++ właśnie do takich rzeczy najlepiej się nadają imho struktury z polami bitowymi, czyli opisujesz konkretne bity w bajcie i możesz się do nich odwoływać. Do tego jest to w pełni kompatybilne z intami czy ile tych bitów potrzebujesz

@baklazan wszystko prawda. Tak, ten enum class dziedziczył z uint32_t.
Co do Rusta, to niestety, programiści są, ale nie znajdziesz pracy poza crypto. Chyba że będzie jakiś biały kruk xd

@ZohanTSW W takim razie pracuję w białym kruku xD

@baklazan gratulacje, mam nadzieję że ten język będzie się popularyzował

@ZohanTSW Póki co mam mieszane uczucia: z jednej strony są rzeczy które zachwycają (np rustowe enumy), z drugiej strony bardzo ograniczone generyki (np. brak variadic'ów powoduje że nie zrobisz generyka przyjmującego więcej niż N typów). Do multum rzeczy musi być w makrach: makra są dużo zajebistsze niż w C++, ale musisz je klepać zamiast zajmować się generykami.

Do tego mam wrażenie, że jest zbyt wymagający jeśli chodzi o poprawność kodu: jako stary wyjadacz C++sa, wiem o wszystkich dziurach które mogą się wydarzyć, ale też wiem kiedy dane sytuacje są niemożliwe, więc mogę sobie odpuścić kolejną warstwę zabezpieczeń. W Rustcie musisz je mieć zawsze i używać ich explicite, co powoduje że mnożą się byty niepotrzebnie.

To są moje pierwsze wrażenia, więc pewnie za rok będę miał więcej mądrzejszych wniosków.

@Shotsel Trudne pytania zadajesz xD

Implementowaliśmy ficzury z cyklu coverage enhancement, na przykład DMRS bundling, repetycje, TBoMS. Ale wszystkie te ficzury musi najpierw wspierać sieć. Ogólne, modem to R17 RedCap (reduced capability), niestety wiele sieci wciąż tego nie wspiera.

Power consumption to jeszcze trudniejsze pytanie. Przede wszystkim, nikt nie dzieli się publicznie konkretnymi numerami. Poza tym, power consumption zależy od całego systemu - możesz mieć super oszczędny modem ale prądożerny wyświetlacz. Dodatkowo, power consumption to kombinacja HW i SW. Jeśli SW jest napisany z głową i nie potrzebuje nie wiadomo jakiego clocka, wtedy power consumption będzie mniejszy. Jedyne, co mogę powiedzieć publicznie w tym temacie, to że najprawdopodobniej modem MTK jest zrobiony w znacznie nowszym procesie niż modemy Intela, które Apple używało wcześniej. Sam ten fakt pewnie pozwoli na znaczny power consumption reduction.

@groman43 myslalem, ze robilscie end-to-end modem i jestes w stanie to jakos porownac. Albo miales dostep do CICD u klienta i widziales jak tam perf testy wygladaly xD
No nic, dzieki za odpowiedz. Wiadomo, ze dopiero caly zintegrowany system mozna oceniac. Pozyjemy, zobaczymy

@Shotsel Tak, robiliśmy end to end modem, ale nie cały produkt. Mamy konkretne numery dla naszego modemu, ale musiałbyś torturować mnie trzy dni, żebym się nimi podzielił.

@groman43 luz, nie mam zamiaru. Tak tylko pytalem o odczucia lepiej/gorzej.
Z mojego doswiadczenia byly projekty, ktore spoko dzialaly i byly takie co wszyscy zgodnie mowili, ze nikt by tego syfu nie kupil xD

@Felonious_Gru The DCF77 transmitted carrier frequency relative uncertainty is 2 × 10−12 over a 24-hour period and 2 × 10−13 over 100 days, with a deviation in phase with respect to UTC that never exceeds 5.5 ± 0.3 microseconds. (Wikipedia, link powyżej).

Nie chodzi tutaj o dokładność synchronizacji pomiędzy nadajnikiem a odbiornikiem, a dwoma odbiornikami zlokalizowanymi w podobnym miejscu. Strona GUM nie podaje jaki jest phase noise e-Czas. Jedyne, co mogłem znaleźć to stwierdzenie "Dokładność synchronizacji odbiorcy końcowego: <0,01 s". Zero informacji, czy chodzi o synchronizację pomiędzy odbiornikiem a nadajnikiem, dwoma odbiornikami, na jakiej odległości. Zero informacji z czego konkretnie wynika ta liczba.

Ogólnie nie widzę sensu dokładnej synchronizacji pomiędzy nadajnikiem a odbiornikami. Synchronizacja pomiędzy odbiornikami w danym miejscu (bo to odbiorniki mają coś "zrobić" w konkretnym czasie) ma znacznie większe znaczenie moim zdaniem.

Edit: Generalnie moim zdaniem tam wszystko jest źle
* Lekko prehistoryczny DSP, mimo że e-Czas wystartował pod koniec 2023
* Brak kodu źródłowego
* Sam protokół też jest z tyłka. CRC jeszcze bym zrozumiał, ale na cholerę im kodowanie RS w czymś takim?

@groman43 no sam widzisz, porownujesz totalnie różne rzeczy.
To już ci porównałem - dcf stoi 900km ode mnie, Solec Kujawski jakieś 200km, już z tego wynika, że opóźnienie jest mniejsze.
Dokładność samego źródła na pewno nie będzie gorsza.

Cudownością DCF77 było to, że te 52 lata temu nie było innej metody, a odbiór był stosunkowo prosty. Wadą jest konieczność utrzymania dobrej jakości odbioru przez 2 minuty żeby mieć pewność, że odbierze się całą ramkę.

Zaletą e-czas jest to, że nie ma potrzeby używania oddzielnego nadajnika. Czas przesylania ramki też jest fantastyczny. W 2 sekundy cala ramka i jest wysyłana chyba co 15 sekund. Wadą jest większe skomplikowanie odbiornika i brak dedykowanych odbiorników w cenie kurzu z półki.

Zaletą obu jest większa odporność na zakłócenia niż gps, wadą obu śmiesznie niska dokładność u odbiorcy końcowego w porównaniu do gps.

@Felonious_Gru Nie, nie porównuję dwóch różnych rzeczy. Sam nie wiem, co porównuję, bo nikt z GUM nie raczył napisać skąd wziął swoje liczby. Zero konkretnych informacji, zero pomiarów, zero niczego.

Długość odbioru ramki nie ma znaczenia. Tak jak napisałem powyżej, interesuje Cię dokładność synchronizacji pomiędzy odbiornikami.

@groman43
> Nie, nie porównuję dwóch różnych rzeczy. 
Nie no, wcale xD
Jeśli dla Ciebnie porównanie bezwględnej dokładności do dewiacji jest czymś normalnym, to nawet nie chce mi się kontynuować tej rozmowy.

Na pewno zgadzamy się, że na 2025r ten wzorzec jest dość chujowy - choć z różnych przyczyn. Mimo to dobrze, że mamy własny wzorzec niezależny od internetu i kosmosu.

@Felonious_Gru Nie zrozumiałeś mnie - może porównuję tą samą rzecz, może porównuję dwie różne rzeczy, może pieć różnych. Po prostu sam nie wiem co czynię, ponieważ GUM nie podał praktycznie żadnych szczegółów technicznych xD

@groman43
Porownujesz dewiację częstotliwości dcf77 z dokładnością dla użytkownika końcowego e-czas radio (przy użyciu konkretnego urządzenia odbiorczego), co sam napisałeś.

@Felonious_Gru Dokładność synchronizacji w DCF77 opiera się na "fazowej" części ramki, dlatego phase noise jest tutaj głównym ograniczeniem.

@groman43
> nie chcę się ściągać specjalnie KiCada. 
Żałuj xD
A na poważnie, to nie jest projekt w kicadzie tylko żywcem zrobiony import z eagle

@groman43 ja pierdziele. Przelotki w padach, brak jakichkolwiek otworów montażowych, ścieżkui byle jak, każda krzywo, wylewki krzywo, no masakra. Zobacz jak poprowdzone jest LED3

@Felonious_Gru Jezus Maria! O co tam chodzi z tym VDD?

@groman43 Ale w którym miejscu, bo co jedno to śmieszniejsze xD

@Felonious_Gru Nie ważne, nie pytałem xD

@groman43 może i się nie znam, ale by mi było wstyd brać pieniądze za to.
Zresztą moje amatorskie plytki z eagle sprzed 20 lat były lepsze
A teraz uczę się powolutku kicada...

@Felonious_Gru Coś mi mówi, że to płytka to dopiero początek. Pewnie kodu źródłowego celowo nie opublikowali, bo było im wstyd.

@groman43 a jest możliwe.
O ile assembler w części dsp mogę zrozumieć to jest len ciekaw reszty