Skocz do zawartości

sosnus

Użytkownicy
  • Zawartość

    458
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    14

sosnus zajął 1. miejsce w rankingu.
Data osiągnięcia: 29 czerwca 2015.

Treści użytkownika sosnus zdobyły tego dnia najwięcej polubień!

O sosnus

  • Urodziny 25.07.1995

Informacje

  • Płeć
    Mężczyzna
  • Lokalizacja
    Jaroszki
  • Moje zainteresowania:
    Sokolnictwo i robotyka

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

Osiągnięcia użytkownika sosnus

Stały bywalec

Stały bywalec (9/19)

  • Za 25 postów
  • Za 5 postów
  • Za 100 postów
  • Starszy redaktor
  • Redaktor

Odznaki

46

Reputacja

  1. Cześć, Skleiłem projekt składający się z: RPi Pico, XBee oraz serw. Z elektroniką i programem wszystko ok, natomiast mam problem z zasięgiem XBEE. Kupiłem dokładnie ten moduł: https://www.tme.eu/pl/details/xb3-24ast-j/moduly-rf/digi-international-inc/ oraz takie anteny do testów: https://www.tme.eu/pl/details/2069940100/anteny-wifi-bluetooth/molex/206994-0100/ oraz https://www.tme.eu/pl/details/1461530100/anteny-wifi-bluetooth/molex/ Jak widzimy na zdjęciu modułu XB3-24AST-J, mamy tutaj duże złącze SMA oraz miejsce na wlutowanie złącza u.fl. W czym jest problem? Wlutowałem złącze u.fl, założyłem te anteny na u.fl które podlinkowałem powyżej. Zapętliłem jakiś komunikat i patrzyłem jak z zasięgiem. Otóż zasięg w tym momencie jest skorelowany z tym w jaki sposób dotykam tego modułu. Raz działa a raz nie. Wygląda to jakby coś gdzieś nie było podpięte, ale raczej o niczym nie zapomniałem. Ten moduł XBEE z istotnych pinów ma tylko transmisję UART, 1xGND i 1xVCC więc raczej o niczym nie zapomniałem. Zrobiłem własny adapter składający się z jednej strony z listwy GPIN 2mm 10 pin a z drugiej strony żeńskie gpiny na kablu (4 sztuki), długość tych kabli ok. 5cm więc mam nadzieję że te kable nie mają wpływu na działanie układu. Ludzie często testują XBEE z użyciem takich adapterów: https://www.adafruit.com/product/126 ale patrząc na schemat tego modułu: to nie ma tutaj nic specjalnego, zwłaszcza że RPi pico pracuje na 3v3 a ta płytka jest przede wszystkim po to aby bezpiecznie komunikować się z Arduino zasilanym z 5V. Niestety nie mam przy sobie anten SMA na 2.4GHz, założyłem do testów tymczasowo antenę na 868MHz SMA i zasięg był znacznie lepszy niż przy antenach 2.4GHz u.fl o których pisałem powyżej. Ok, opisałem jak wygląda mój case, a teraz kilka pytań: 1. Dlaczego aktualnie moduł działa lepiej na antenie SMA 868MHz niż na antenie u.fl 2.4GHz? Mam wrażenie że ta antena na u.fl wcale nie wzmacnia sygnału 2. Czy uruchomienie takiego modułu bez żadnej anteny może go uszkodzić? 3. Czy połączenie RPi Pico oraz XBEE za pomocą kabelków 5cm może wprowadzać jakieś dodatkowe zakłócenia? 4. Jak sprawdzić czy antena na złączu u.fl spełnia swoją rolę czy nie? 5. Jaką antenę SMA najlepiej kupić do takiego modułu? Czym się kierować czy doborze anteny? 6. Czy taka przedłużka SMA: https://www.tme.eu/pl/details/ad.ant.013/kable-polaczeniowe-koncentryczne/jc-antenna/ może wpłynąć negatywnie na zasięg? Nie chciałbym ciężkiej anteny SMA przytwierdzać na stałe do modułu XBEE gdyż obawiam się wstrząsów, wolałbym przymocować ją do obudowy i połączyć przedłużką na przykład taką jaką podałem powyżej 7. Czy serwa mogą wprowadzać zakłócenia które zmniejszą zasięg XBEE?
  2. Minęło już trochę czasu od publikacji tego artykułu, są jakieś nowe wieści nt. dostępności RPI Pico W / WH?
  3. Dzięki! Wracam do tematu, niedługo testy, zamierzam przede wszystkim: 1. ustawić prędkości przesyłu na jak najmniejsze 2. kupić lepszą antenę Jest jeszcze jedna kwestia: w tym momencie blisko anteny (~3 cm) znajdują się dwa mikroserwa, ale poruszają się one tylko na rozkaz z telemetrii, więc możemy wyjść z założenia że nie pracują intensywnie w momencie odbierania komunikatów - w związku z tym mogą "siać" i zakłócać antenę? Przypominam że w tym momencie testuję wszystko na defaultowych antenach z zestawu z 3DR. W domu znalazłem jeszcze taką antenkę którą kiedyś kupiłem: https://www.tme.eu/pl/details/433m-ant401/anteny-rf/sr-passives/ warto ją sprawdzić czy raczej też będzie mocno odstawać od tych które wymieniłem niżej pod linkiem qlrs.pl ? Dzięki, w takim razie rezygnuję z Mavlinka i wracam do swojej banalnej ramki którą już zaimplementowałem Co do anten, ten sklep wygląda ciekawie, która antena najlepiej się sprawdzi w moim case według Ciebie? http://qlrs.pl/anteny-lrs-433-mhz Dipol wydaje się cholernie długi, dipol pod kątem "Y" byłby szerszy od mojego urządzenia więc też bym się starał go uniknąć, oczywiście najbardziej mi się podoba "micro antena" do racerów, ale nie wiem czy nie za słaba i nie za delikatna. Rozumiem że najlepiej kupić obie takie same anteny (do telefonu i do urządzenia)? nadal przewiduję trzymanie tego w ręku, więc nie chciałbym aby antena przy telefonie była zbyt duża i niewygodna w użyciu.
  4. I to są już konkretne odpowiedzi, bardzo dziękuję! 😄 No właśnie jeszcze nie implementowałem żadnego heartbeata, teraz mam ciągłe nasłuchiwanie i czekanie, wysyłanie komend tylko jeżeli moduł został o to poproszony z ziemi. Tak więc nie mam heartbeata, a moduł raz działa a raz nie. Dioda led zielona ciągle się świeci w module który jest na ziemi nawet jeżeli moduł w górze przestał odpowiadać na moje komendy (o ile dobrze pamiętam bo kilka dni temu ostatnio testowałem) Wcale nie przewiduję współpracy w QG, na przyszłość tylko moja własna apka, ale użyłem QG w ramach testu komunikacji i zasięgu, i o dziwo QG ciągle dostawało Heartbeaty od modułu z powietrza, nawet z odległości przy której aplikacja serialport (którą później zamienię na swoją aplikację) już nie dostawała odpowiedzi... Trochę się zraziłem do E32 i nie wiem czy chce mi się do niego wracać ale skoro tak mówisz to może rozważę kwestię jeszcze raz... Pierwotnie zakładałem że odbiornikiem nie będzie telefon a DIY "pilot" z Arduino i ekranikiem w środku, ostatecznie stwierdziłem że użycie telefonu jako pilota jest tańsze i daje szersze pole do popisu, i na tym etapie właśnie przeszedłem z testów E32 na testy 3DR bo już mnie szlak trafiał prazy testowaniu, bo nie wiedziałem czy błąd jest po stronie kodu (modułu w powietrzu/pilota) czy po stronie komunikacji, postanowiłem uprościć to do minimum i zlikwidować fizyczny pilot. Chociaż prawdę mówiąc chyba nic mnie nie blokuje przed użyciem E32 w tandemie z telefonem... Podsumowując: Czy miałbym jakiekolwiek korzyści z zaimplementowania Mavlinka w danej sytuacji? Wiem że mavlink został stworzony tak aby generalnie przez swoją prostotę być właśnie odpornym na zakłócenia, szumy, etc. ale w tym przypadku czy ma to sens? Zwykły serialport kablowy przy długich kablach/zakłóceniach/złych prędkościach przesyła krzaki a co z 3DR/E32? przepuszcza krzaczki czy ma jakąś własną dodatkową kontrolę błędów?
  5. Skoro program SmartAudioBook Ci odpowiada, to może po prostu łatwiej by było dorobić jakies sterowanie tą aplikacją za pomocą zewnętrznej elektroniki? Jakiś czas temu był artykuł na Forbocie o dodatkowych fizycznych przyciskach na obudowie smartfona lecz teraz nie mogę znaleźć tego artykułu. Generalnie: a gdyby zamiast robić elektronikę od zera, to sterować aplikacją która już istnieje albo z poziomu smartwatcha albo jakiejś customowej elektroniki? Nie wchodziłem jeszcze za bardzo w temat ale to chyba wydaje się być możliwe do wykonania.
  6. Powtarzam, robię projekt który ma być łatwo odczepiany od drona, więc to nie jest integralna część drona i z samym dronem nie ma nic wspólnego - nie mam więc dostępu do Mavlinka oraz sensorów na dronie, musiałbym te kilka mi potrzebnych komend zaimplementować sam na podstawie dokumentacji (albo użyć jakiejś gotowej, najprawdopdobniej ciężkiej biblioteki i użyć tylko promila jej funkcjonalności) więc pytanie czy to jest tego warte. Jakie parametry potrzebuję? Przede wszystkim wysokość i stan baterii tego urządzenia. Rpi musi też wykonywać niektóre proste czynności o które go poproszę (na początek np. zapalenie/zgaszenie diody Led). Generalnie jestem w szoku że QGround sobie radzi, a prosty serialport sobie nie radzi i zastanawiam się czy zaimplementowanie kilku komend z Mavlinka pomoże/rozwiąże sprawę i gdzie leży problem. Zastanawiam się czy całkowicie nie porzucić telemetrii i nie znaleźć jakiegoś lepszego kanału komunikacji. Testowałem też moduły znane w internecie pod nazwą "E32 TTL" (różnie to jest nazywane) ale to też straszny paździerz jest.
  7. Cześć, mam pewien problem z telemetrią. Generalnie to robię prosty projekt, gdzie telemetria modelarska (3dr) jest używana jako moduł UART zamiast bluetooth, bo oczywiście BT nie ma tak dużego zasięgu jak telemetria. W ramach testów spiąłem RPi Pico z telemetrią, podwiesiłem pod drona i puściłem w niebo. Na ziemi zostaje telefon z modułem 3dr podpiętym pod telefon z Androidem i aplikacją serialport. Gdy w linii prostej przekraczam 100 metrów, to pomimo tego że nic mi nie stoi na drodze to są momenty że na kilkanaście sekund tracę komunikację - RPi nie odpowiada na moje zapytania, ale gdy podlecę bliżej to komunikacja wraca. Nie mam absolutnie pojęcia co powoduje tymczasową utratę komunikacji. Żeby było ciekawiej, to podczas lotu wyłączam aplikację serialport, odpalam qgroundstation, łączę się i oglądam wykres jakości sygnału z telemetrii i... wszystko jest ok, qground wcale nie zrywa połączenia. QGround używa protokołu Mavlink, a ja zwykłej transmisji szeregowej - czy to również ma znaczenie? powinienem swoją komunikację rozpisać pod Mavlink zamiast wysyłania pojedynczych znaków czy stringów? Potrzebuję tylko kilka zmiennych raz na kilka sekund. tl;dr: Jakie mogą być powody że telemetria zostaje zakłócona nawet przy stosunkowo małych odległościach? Czy warto implementować Mavlinka czy zwykła praca na charach/stringach tutaj wystarczy? Dlaczego QGround nie traci ani jednego heartbeata mavlinka, a moje komunikaty z aplikacji serialport nie dochodzą pomimo tej samej odległości. Moja aplikacja pracuje na defaultowych ustawieniach telemetrii (prędkość przesyłu, itp.). Pytanie czy QGround nie zmienia tymczasowo konfiguracji ale wątpię w to. Generalnie czy 3dr jest dobrym pomysłem na komunikację na odległość rzędu 1 czy 2 kilometry? Może warto by było przerzucić się na LoRa, choć nie ukrywam że banalny UART jak przy telemetrii brzmi ciekawiej. Warto dalej trzymać się 3dr czy może coś nowszego proponujecie? Nie ukrywam że to już jest stary sprzęt i w PL są już duże problemy z dostępnością. Czy w opisanym przypadku telemetria dronowa jest dobrym rozwiążaniem czy może jednak lepiej przerzucić się na jakąś inną komunikację? Aktualnie na rynku mamy przecież szeroką konkurencję: nowe standardy Bluetooth, WiFi, Zigbee, XBee, LoRa, etc. Byłbym wdzięczny na odpowiedź chociaż na jedno z powyższych pytań, każda odpowiedź jest na wagę złota bo sam już długo nad tym myślę i kończą mi się pomysły na rozwiązanie problemu. Jedyne czego jeszcze nie sprawdziłem to pracy urządzenia na najniższych ustawieniach prędkości przesyłu telemetrii ale to nie powinno być problemem skoro QGround sobie radzi.
  8. Też polecam Grafanę, zazwyczaj jako źródło danych do Grafany używam InfluxDB, jest banalne w użyciu i bardzo łatwe do połączenia nawet z prostymi mikrokontrolerami o ile mają jakiś interfejs sieciowy. Takie ESP8266 bez problemu może robić zapytania HTTP do InfluxDb i jest to banalne, dzięki temu bez problemu możemy sobie oczujnikować np. dom. Świetne są też integracje Grafany z innymi aplikacjami, ja sobie skonfigurowałem tak że w przypadku braku odczytów z czujników (wyczerpana bateria lub brak internetu) dostaję powiadomienie na Discordzie. PS. Jeżeli interesują nas czyste dane bez obróbki to tym bardziej polecam InfluxDB, akurat mam pod ręką przykład to wklejam przykładowe instrukcje zapisu pojedynczego rekordu i odczytu tabeli dla InfluxDB ADDR_INFLUX=sekretny-adres-strony.pl PORT_INFLUX=8086 # write data curl --location --request POST http://$ADDR_INFLUX:$PORT_INFLUX/write?db=greenhouse_jaroszki \ --header 'Content-Type: text/plain' \ --data-raw 'temperature,device=greenhouse01 value=0.2' # read data curl --location --request POST http://$ADDR_INFLUX:$PORT_INFLUX/query?db=greenhouse_jaroszki \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'q=SELECT * FROM temperature' PS2. Widzę że ostatni post 8 lutego ale ja trafiłem tutaj przeglądając laureatów konkursu, tak więc @MichalGiza gratuluję wyróżnienia ;)
  9. "Zapowiedziano też wydanie dwóch shieldów: Arduino LoRa Gateway i Arduino LoRa Node." Wiadomo kiedy podadzą datę premiery? 😉
  10. A kurs Naelektryzowanego kolega widział? 😉 https://www.forbot.pl/forum/topics20/kurs-tworzenie-wlasnej-aplikacji-android-do-sterowania-przez-bluetooth-cz-1-vt9135.htm
  11. No przecież od tego jest ten kurs 😉 Zacytuję Ci końcówkę tego kursu: Wniosek? Piszesz aplikację DOKŁADNIE jak w tym kursie, i aplikacja wysyła bajt "10" lub "11", a z tego co napisałeś powyżej to chyba wiesz jak wysyłając bajt "10" lub "11" zmienić wartość leda w Arduino, tak? 😉 Najważniejsze co musisz sobie wyjaśnić, to różnica między znakami ASCII a wartością bajtów, ale mam nadzieję że to nie jest problem 😉
  12. sosnus

    Silnik jako prądnica

    tak z ciekawości - widziałeś to? 😉 https://botland.com.pl/generatory-pradu/4426-generator-wodny-36v-250mah-gwint-12.html
  13. Na szybko stworzyłem dwa pady, spójrz proszę w załacznik do tego posta - o to Ci chodziło? 😉 PS. Nie iwme co jest, zapisałem zdjęcie jako .png, jako .gif oraz .jpg i ŻADNEGO zdjęcia nie zaakceptował mi serwer forbota, to zły format 🙁
  14. Dokładnie. To co robimy w tej sytuacji? 😃
  15. Harnas, tego się nie spodziewałem 😃 Masz coś jeszcze ciekawego na Microsoft Store/Google Play/Apple Store? 😃 Opłacało się kupić płatne konto deweloperskie?
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.