piotrva

@Sabre Może druk 3d i własne joysticki

@Sabre Może kup jakieś joysticki od większych aparatur?

@ak95 Można zawsze dodać nieliniową korektę - np. TG9x po zmianie FW na ER9x ma opcje definiowania nieliniowych krzywych do przeliczania wejścia z joysticka na wyjście na dany kanał. @Treker Jeśli odbiornik ma wyjście PPS to nie tak trudno, ale fakt, tu można na 100% więcej samemu pogrzebać w samej komunikacji i mieć od razu 2 kierunki transmisji.

Pytanie tylko jaki koszt całości i czy nie lepiej kupić gotową aparaturę (oczywiście pomijając walory edukacyjne i satysfakcję z konstrukcji)

Zrobiłem parę dni temu podobny tylko, ze w oparciu o sensor time-of-flight

Cóż, mam podobne zdanie, lubię rozwiązania, które są open source. Jak np. gitlab. Mogę postawić sobie na swoim sprzęcie, a mogę skorzystać z ich serwerów. Czy Arduino Cloud będzie open-source, jak reszta? Co do klonów - to klony może powstrzymać tylko jedno - brak opłacalności ich produkcji. Dlatego np. nikt nie klonuje Analog Discovery 2 Chyba największą ofiarą klonów była firma USBee - przez to, że ludzie na potęgę klonowali ich układy - zwinęli się z rynku na pare lat. Teraz niedawno wrócili z odświeżoną ofertą.

Takich staroci bym nie kupował, z fajnych płytek to u przyjaciół ze wschodu są takie: ALTERA FPGA Development board CYCLONE IV NIOS EP4CE6 EP4CE10 Study Board Wersja z programatorem i mniejszym FPGA (E6) kosztuje teraz 62 USD, zaś z większym (E10) 80 USD. Tu nieco dokumentacji wyciągniętej od majfrendów: https://gitlab.com/piotrva/ax301b-examples

Ja bym powiedział, że nie warto tego robić. po to są języki HDL (Verilog, VHDL), aby np. szybko zaprojektować automat stanów (piszesz 10 mądrych linijek i już), a nie męczyć się z kodowaniem tego na bramkach.

Ponieważ chodzi o to aby w optymalny sposób przekazać możliwie największe pole magnetyczne (aby przewodzić możliwie duży strumień pola) między jednym a drugim uzwojeniem. Dodatkowo wymagane jest aby materiał był możliwie "miękki" magnetyczne - miał minimalną pętle histerezy, czyli łatwo się przemagnesowywał.

@deshipu Ale jakich ekspertów? Dajesz ludziom choćby podlinkowaną bibliotekę od ST do szyfrowania i po problemie. Ewentualnie każesz dołożyć scalaka szyfrującego, bierzesz do niego przykładowe kody i po problemie - na prawdę nie widzę powodu, aby średnio rozgarnięty inżynier nie poradził sobie ze zrobieniem czegoś takiego - ja parę lat temu, gdy moja wiedza była znikoma w tych dziedzinach postawiłem pełne szyfrowanie TLS na ESP8266 (TLS, czyli to samo na czym bazuje SSL/HTTPS). A był to bzdetny projekt nadajnika podczerwieni do zdalnego sterowania urządzeniami z dowolnymi protokołami IR.

@deshipu o jakich 400$ mówisz? Przy masowej produkcji koszty porządnego protokołu szyfrowania będą znikome. @Elvis Zapomnijmy o Arduino i AVR - one są woooooolne - taki np. STM32 bez problemu policzy sobie nawet RSA: https://www.st.com/content/ccc/resource/technical/document/user_manual/34/1a/20/75/7f/84/45/cb/CD00208802.pdf/files/CD00208802.pdf/jcr:content/translations/en.CD00208802.pdf I jakie 20-30kB na sekundę? Pomiar temperatury to jest... 4 bajty na pomiar, zakładając nawet jakiś overhead, adres, etc, powiedzmy 16 bajtów. Temperaturę musisz czytać co sekundę? wątpię - wystarczy raz na minutę Wiadomo są inne pomiary, ale raczej jak mamy wysoki update rate to i ni wymagamy życia na baterii przez lata -> można dać mocniejszy procesorek. @deshipu to że komunikat krótki, nie oznacza, ze klucz jest krótki - wystarczy AES512 czy 1024 i KONIEC.

@deshipu Mówię o stosownym szyfrowaniu, takim przy którym złamanie dla potencjalnego włamywacza będzie nieopłacalne. Rozróżnijmy 2 produkty: a) czujnik temperatury bezprzewodowy do stacyjki pogodowej na biurko b) czujnik temperatury bezprzewodowy do sterowania ogrzewaniem CO ten pierwszy mogę kupić za 2 dolary, może być bez szyfrowania, nie obchodzi mnie to bo co najwyżej zobaczę, że mi wyświetla milion stopni na zewnątrz (+ lub -) i stwierdzę, że do kitu. Ten drugi - mogę dać i 40$ - chcę coś niezawodnego. i czy od razu muszę mieć skomplikowaną obsługę, etc? Można na prawdę wymianę takich kluczy zrobić transparentną dla użytkownika, albo jakieś jednoczesne wciśnięcie przycisku na centralce i czujniku (niby może ktoś wtedy podsłuchać radio), albo podpięcie jakiegoś kabelka na chwilę czy zrobienie tego samego ze specjalnie zmniejszoną mocą (pt. przyłóż antenkę jednego do drugiego i wciśnij guziki). Dla mnie żaden problem ze strony użytkownika, ze strony producenta - kwestia przemyślenia sprawy. @Elvis moduły 433 MHz - tego nie powinni dopuścić do sprzedaży, widziałeś tego widmo? Ja dziś wyjąłem jeden i chcę zobaczyć jego widmo na nowym SDR, bo na RTL-SDR, którym kiedyś to chciałem zobaczyć widmo wyszło poza jego zakres I tu nie chcę nawet tego widzieć w jakimkolwiek urządzeniu, nie mówiąc o rozmyślaniu czy szyfrować dane czy nie. Aczkolwiek - szyfrować można Tak czy siak dyskusje można podsumować - szyfrować w aplikacjach krytycznych, w innych olać sprawę A wracając do dyskusji o tym chipie w Arduino - mi się wydaje, że czy to będzie do szyfrowania użyte, czy podpisywania wiadomości celem odmowy dostępu do chmury ludziom nie będącymi klientami - mają prawo tak zrobić, bo oni będą tę chmurę utrzymywać. Są takie moduły Particle: https://www.particle.io/cellular i tam u nich kupujesz abonament na transmisję danych i masz wtedy dostęp do ich chmury. Chcesz co innego? Wkładasz inna kartę SIM i bawisz się sam - są schematy dostępne i kody. Tu mogłoby być podobnie - kupujesz naszą płytkę - korzystaj dożywotnio z chmury. Kupujesz klona? zobacz na źródła naszych serwerów chmurowych, postaw sobie na swoim serwerze i baw się dalej - ja bym przynajmniej tak zrobił

Poniższy post został wydzielony jako początek nowej dyskusji z poniższego tematu: ----------- Mówicie dużo, że szyfrowanie nieistotne itp. itd. Moim zdaniem lepiej wprowadzać szyfrowanie od najmniejszych układów. Bo potem dojdziemy: a po co szyfrować, to tylko żarówka. I jakiś domorosły idiota zrobi nam dyskotekę oświetleniem dla żartów. Plus nie wiem czy widzieliście jak goście hakowali... sterowanie zdalne dźwigów i suwnic itp. Wyobraźcie sobie ile szkody (w tym na życiu ludzkim) może spowodować przejęcie kontroli nad czymś w hucie stali na przykład... A projektanci systemów też myśleli - po co szyfrowanie, przecież kto by się do tego włamywał - ma działać pewnie i tyle...

Hmm, choćby włamywacz podszywa się za czujnik i wysyła że mamy cały czas temperaturę 0 - przez to ogrzewanie grzeje na maska i cóż... Co do samego chipu - można na razie tylko spekulować, czy to nowy feature i udogodnienia dla użytkownika wraz z możliwością dodatkowego zabezpieczenia się, czy tez rzeczywiście krok w stronę ukrócenia rynku klonów. Szczerze nie dziwiłbym się, gdyby tak było jeśli chodziłoby o rozwiązania chmurowe - kupujesz nasz produkt - korzystaj. Kupujesz klona - radź sobie sam. Przykładem na to, że zapomniano o tym może być sprawa analizatorów stanów logicznych: Saleae i USBee - są one obecnie klonowane na potęgę, firmy, które zrobiły dobry soft (w szczególności Saleae) nie mają z tego dochodu (a ruch na ich stronach w związku np. z pobieraniem softu jest generowany => ponoszą koszty). Nie mają tez jak zablokować klonów, bo są nie od odróżnienia od oryginałów...

Mnie najbardziej przekonuje to ostatnie, czyli, że i tak trzeba by programator / debugger do FPGA. Bo tak to można by tam na stałe wgrać typowy Nios II z typowymi peryferiami (UART, SPI, I2C, PWM, Timery) i kompilować normalnie projekty na taką platformę. Tak czy siak fajne podejście do tematu ;)