Telemetria 3dr jako moduł UART do Raspberry Pi Pico - problemy z zasięgiem

[sosnus]

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:

1. Jakie mogą być powody że telemetria zostaje zakłócona nawet przy stosunkowo małych odległościach?
2. Czy warto implementować Mavlinka czy zwykła praca na charach/stringach tutaj wystarczy?
3. Dlaczego QGround nie traci ani jednego heartbeata mavlinka, a moje komunikaty z aplikacji serialport nie dochodzą pomimo tej samej odległości.
4. Moja aplikacja pracuje na defaultowych ustawieniach telemetrii (prędkość przesyłu, itp.). Pytanie czy QGround nie zmienia tymczasowo konfiguracji ale wątpię w to.
5. 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.
6. 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ą.
7. 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.

[farmaceuta]

Wiele Ci nie pomoge ale...

Jak potrzebujesz tylko kilka zmiennych (rozumiem ze o parametry Ci chodzi) to odpytujesz mavlinka o ktore dane Ci chodzi...

Ja nie korzystalem z 3dr, ale rozumiem ze masz wersje na 433/800-cos tam Mhz wiec tutaj zasiegi rzedu kilka km to nic....podstawa?? Anteny!! Jak masz te oryginalne baciki to nic sensownego na tym nie zrobisz...mozna sobie samemu zrobic dipole (proste jak drut) i nawet nie mierzone wedlug kalkulatora beda o niebo lepsze niz tamto dziadostwo...

A co Ty tak dokladnie chcesz przesylac??

[sosnus]

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.

[farmaceuta]

5 godzin temu, sosnus napisał:

więc to nie jest integralna część drona i z samym dronem nie ma nic wspólnego 

Teraz juz jest jasne...

 

5 godzin temu, sosnus napisał:

musiałbym te kilka mi potrzebnych komend zaimplementować sam na podstawie dokumentacji (albo użyć jakiejś gotowej, najprawdopdobniej ciężkiej biblioteki 

Akurat w przypadku Rpi to o rozmiar bym sie nie martwil...nie wiem jak z kompatybilnoscia...bo oczywiscie biblioteka jest pod zaskakujaca nazwa "mavlink" 

Mawlink wysyla cale pakiety z indeksami i id (zeby bylo wiadomo ktory pakiet jest ktory) jezeli jestes obyty w programowaniu to zapewne te kilka parametrow ogarniesz bez biblioteki bo to wkoncu tylko pakiet o okreslonych zmiennych itp...a jezeli chcialbys uzyc biblioteki to jest gdzies na githubie cos o nazwie "arduino mavlink simulator"...prosty kawalek kodu ktory imituje model, wysyla heartbeaty etc...akurat tam bylo napiecie, wysokosc, predkosc etc...(kompas jedynie mi nie chodzil..sprawdzane z Mission Planner)

5 godzin temu, sosnus napisał:

 Rpi musi też wykonywać niektóre proste czynności o które go poproszę (na początek np. zapalenie/zgaszenie diody Led).

No to tutaj to wyslesz jakis bajt swoim "protokolem" i tyle...zero kolizji...(w Rpi sam sobie ustalisz z jaka czestotliwoscia ma wysylac dane...jedyne to HeartBeat chyba co 1Hz obowiazkowo musi zasuwac zeby komunikacja byla z apka)

5 godzin temu, sosnus napisał:

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.

No wiesz...jezeli zmienisz radio, ale dalej bedziesz chcial miec parametry w QG to dalej jestes w tym samym punkcie bo ta apka bedzie tylko wspolpracowac z protokolem mavlink...

 

5 godzin temu, sosnus napisał:

Testowałem też moduły znane w internecie pod nazwą "E32 TTL" (różnie to jest nazywane) ale to też straszny paździerz jest.

Pod jakim wzgledem?? Jesli sie nie myle to te moduly uart 1 watt tak? ...jesli tak to na nich powstal taki link "Qczek LRS" (przez polaka zrobiony) i jesli chodzi o cena-jakosc-mozliwosci to jest to najlepszy chyba link na swiecie Rc...bije rekordy innych lrs z palcem w d....

U mnie burze przeszly i zasieg tel. wysiadl...🤔 jutro jak nie znajdziesz to zerkne u siebie bo powinienem miec przyklady na ardu z czasow jak sie tym mavlinkiem bawilem...

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[sosnus]

I to są już konkretne odpowiedzi, bardzo dziękuję! 😄

2 godziny temu, farmaceuta napisał:

.jedyne to HeartBeat chyba co 1Hz obowiazkowo musi zasuwac zeby komunikacja byla z apka

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)

2 godziny temu, farmaceuta napisał:

ale dalej bedziesz chcial miec parametry w QG

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...

 

2 godziny temu, farmaceuta napisał:

jesli chodzi o cena-jakosc-mozliwosci to jest to najlepszy chyba link na swiecie

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?

[farmaceuta]

8 godzin temu, sosnus napisał:

Wcale nie przewiduję współpracy w QG, na przyszłość tylko moja własna apka

No to nie pchal bym sie w Mavlinka...QG potrzebuje mavlinka wiec takiego protokolu trzeba uzyc, ale jesli mialbys robic wlasna apke, czyli masz pelna kontrole nad tym co i jak odbierasz to wlasny "protokol" bylby duzo lepszym wyjsciem...

Generalnie jest tak ze mavlink jest bardzo popularny w swiecie rc...nie ma chyba drugiego takiego protokolu o takich mozliwosciach i ilosci danych...ale wielu go tez przeklina bo twierdza ze jest trudny w implementacji i zasobozerny w sensie typow danych...operuje glownie na floatach...a w dawnych czasach to glownie na atmegach go poganiano wiec duzo czasu zajmowalo obrobienie tych danych no i przesyl w powietrzu...

8 godzin temu, sosnus napisał:

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...

Rozwaz...ja nie korzystalem, ale testy w sieci pokazuja potege tego modulu...na rc forach wiele osob robilo testy po ziemi i zasiegi bily na glowe inne systemy oparte miedzy innymi na si4432(?)... Wada tych modulow  jest to ze predkosci w powietrzu nie sa wielkie...jak wiadomo zasieg zalezy od predkosci, im wolniej tym dalej (wedlug teorii a i w praktyce to sie potwierdza)..

 

8 godzin temu, sosnus napisał:

 a co z 3DR/E32? przepuszcza krzaczki czy ma jakąś własną dodatkową kontrolę błędów?

Nie wiem tego, ale raczej napewno ma zabezpieczenia...oczywiscie pakiet moze sie uszkodzic...np. e32 ma w bibliotece wykrywanie bledow..3DR tez na pewno ma swoje zabezpieczenia...

 

9 godzin temu, sosnus napisał:

Podsumowując:

Czy miałbym jakiekolwiek korzyści z zaimplementowania Mavlinka w danej sytuacji?

Jezeli mialo by to wspolpracowac z kontrolerem rc to tak...bo jakos musisz te dane wyciagnac..

Jesli planujesz swoja aplikacje to moim zdaniem nie ma sensu sie w to pchac...

Ale do testow jak teraz to bez problemu mozesz kombinowac... Zaraz wkleje Ci ten kod bo znalazlem (z MP dziala...z QG nie polaczylem sie bo mam zrypany blue w tel i czesto mam spory problem polaczyc sie z niektorymi urzadzeniami blue)

[farmaceuta]

// Arduino MAVLink Simulation
//
// (c) 2019 David Wyss
//
// Base Arduino to MAVLink code from https://github.com/alaney/arduino-mavlink

#include <mavlink.h>
#include <SoftwareSerial.h>

SoftwareSerial Seria(2, 3); //RX2//TX3// 

// Parameter setup
// These parameters may be entered manually, parsed from another protocol or simulated locally.
// If your input protocol does not provide values for all of these, parameters may be left at their default values.
// All parameters set here are passed onward through serial output in MAVLink format.

//Basic UAV Parameters
uint8_t system_id = 1;        // MAVLink system ID. Leave at 0 unless you need a specific ID.
uint8_t component_id = 0;     // Should be left at 0. Set to 190 to simulate mission planner sending a command
uint8_t system_type = 1;      // UAV type. 0 = generic, 1 = fixed wing, 2 = quadcopter, 3 = helicopter
uint8_t autopilot_type = 0;   // Autopilot type. Usually set to 0 for generic autopilot with all capabilities
uint8_t base_mode = 81;     //ARM_DISARM!!!! Flight mode. 4 = auto mode, 8 = guided mode, 16 = stabilize mode, 64 = manual mode
uint32_t custom_mode = 11;     // Usually set to 0          
uint8_t system_state = 3;     //?????? 0 = unknown, 3 = standby, 4 = active
uint32_t upTime = 0;          // System uptime, usually set to 0 for cases where it doesn't matter

// Flight parameters
float roll = 0;         // Roll angle in degrees
float pitch = 30;        // Pitch angle in degrees
float yaw = 0;          // Yaw angle in degrees
int16_t heading = 32;      // Geographical heading angle in degrees
float lat = 50.736468;    // GPS latitude in degrees (example: 47.123456)
float lon = 21.445291;     // GPS longitude in degrees
float alt = 123.0;        // Relative flight altitude in m
float groundspeed = 43.7; // Groundspeed in m/s
float airspeed = 0.0;    // Airspeed in m/s
float climbrate = 0.0;    // Climb rate in m/s, currently not working
float throttle = 34.0;     // Throttle percentage


// GPS parameters
int16_t gps_sats = 12;    // Number of visible GPS satellites
int32_t gps_alt = 0.0;  // GPS altitude (Altitude above MSL)
float gps_hdop = 1.5;     // GPS HDOP
uint8_t fixType = 3;      // GPS fix type. 0-1: no fix, 2: 2D fix, 3: 3D fix

// Battery parameters
float battery_remaining = 0.0;  // Remaining battery percentage
float voltage_battery = 12.0;    // Battery voltage in V
float current_battery = 6.0;    // Battery current in A


void setup() {
  
   // Enable serial output. Default: 57600 baud, can be set higher if needed
   Serial.begin(57600);
   Seria.begin(57600);
}



//Main loop: Send generated MAVLink data via serial output
void loop() {
  if (millis() >10000) {
    for (byte i =0; i<1; i++) {
      base_mode = 209;
    }
  }

 lat = lat - 0.000100;    // GPS latitude in degrees (example: 47.123456)
 lon = lon - 0.000100; 

 alt++   ;     
 groundspeed++;
 
 throttle++;
 voltage_battery =  voltage_battery + 0.1;


  // Send MAVLink heartbeat
  command_heartbeat(system_id, component_id, system_type, autopilot_type, base_mode, custom_mode, system_state);

  //Send battery status
  command_status(system_id, component_id, battery_remaining, voltage_battery, current_battery);

  // Send GPS and altitude data
  command_gps(system_id, component_id, upTime, fixType, lat, lon, alt, gps_alt, heading, groundspeed, gps_hdop, gps_sats);

  // Send HUD data (speed, heading, climbrate etc.)
  command_hud(system_id, component_id, airspeed, groundspeed, heading, throttle, alt, climbrate);

  // Send attitude data to artificial horizon
  command_attitude(system_id, component_id, upTime, roll, pitch, yaw);

  //Delay: send messages at about 10Hz
  delay(100);
}



/************************************************************
* @brief Sends a MAVLink heartbeat message, needed for the system to be recognized
* @param Basic UAV parameters, as defined above
* @return void
*************************************************************/

void command_heartbeat(uint8_t system_id, uint8_t component_id, uint8_t system_type, uint8_t autopilot_type, uint8_t base_mode, uint32_t custom_mode, uint8_t system_state) {

  // Initialize the required buffers
  mavlink_message_t msg;
  uint8_t buf[MAVLINK_MAX_PACKET_LEN];
 
  // Pack the message
  mavlink_msg_heartbeat_pack(system_id,component_id, &msg, system_type, autopilot_type, base_mode, custom_mode, system_state);
 
  // Copy the message to the send buffer
  uint16_t len = mavlink_msg_to_send_buffer(buf, &msg);
 
  // Send the message
  Seria.write(buf, len);
}


/************************************************************
* @brief Send some system data parameters (battery, etc)
* @param 
* @return void
*************************************************************/
       
void command_status(uint8_t system_id, uint8_t component_id, float battery_remaining, float voltage_battery, float current_battery) {

  // Initialize the required buffers
  mavlink_message_t msg;
  uint8_t buf[MAVLINK_MAX_PACKET_LEN];

  // Pack the message
    mavlink_msg_sys_status_pack(system_id, component_id, &msg, 32767, 32767, 32767, 500, voltage_battery * 1000.0, current_battery * 100.0, battery_remaining, 0, 0, 0, 0, 0, 0);

  // Copy the message to the send buffer
  uint16_t len = mavlink_msg_to_send_buffer(buf, &msg);
  
  // Send the message (.write sends as bytes)
  Seria.write(buf, len);
}


/************************************************************
* @brief Sends current geographical location (GPS position), altitude and heading
* @param lat: latitude in degrees, lon: longitude in degrees, alt: altitude, heading: heading
* @return void
*************************************************************/

void command_gps(int8_t system_id, int8_t component_id, int32_t upTime, int8_t fixType, float lat, float lon, float alt, float gps_alt, int16_t heading, float groundspeed, float gps_hdop, int16_t gps_sats) {

  // Initialize the required buffers
  mavlink_message_t msg;
  uint8_t buf[MAVLINK_MAX_PACKET_LEN];

  // Pack the message
  mavlink_msg_gps_raw_int_pack(system_id, component_id, &msg, upTime, fixType, lat * 10000000.0, lon * 10000000.0, alt * 1000.0, gps_hdop * 100.0, 0, groundspeed, 0, gps_sats);

  // Copy the message to the send buffer
  uint16_t len = mavlink_msg_to_send_buffer(buf, &msg);

  //Send globalgps command
  command_globalgps(system_id, component_id, upTime, lat, lon, alt, gps_alt, heading);
  
  // Send the message (.write sends as bytes)
  Seria.write(buf, len);
}

/************************************************************
* @brief Send some core parameters such as speed to the MAVLink ground station HUD
* @param 
* @return void
*************************************************************/
       
void command_hud(int8_t system_id, int8_t component_id, float airspeed, float groundspeed, int16_t heading, float throttle, float alt, float climbrate) {

  // Initialize the required buffers
  mavlink_message_t msg;
  uint8_t buf[MAVLINK_MAX_PACKET_LEN];

  // Pack the message
  mavlink_msg_vfr_hud_pack(system_id, component_id, &msg, airspeed, groundspeed, heading, throttle, alt * 1000.0, climbrate);

  // Copy the message to the send buffer
  uint16_t len = mavlink_msg_to_send_buffer(buf, &msg);
  
  // Send the message (.write sends as bytes)
  Seria.write(buf, len);
}

/************************************************************
* @brief Send attitude and heading data to the primary flight display (artificial horizon)
* @param roll: roll in degrees, pitch: pitch in degrees, yaw: yaw in degrees, heading: heading in degrees
* @return void
*************************************************************/
       
void command_attitude(int8_t system_id, int8_t component_id, int32_t upTime, float roll, float pitch, float yaw) {

  //Radian -> degree conversion rate
  float radian = 57.2958;

  // Initialize the required buffers
  mavlink_message_t msg;
  uint8_t buf[MAVLINK_MAX_PACKET_LEN];

  // Pack the message
  mavlink_msg_attitude_pack(system_id, component_id, &msg, upTime, roll/radian, pitch/radian, yaw/radian, 0, 0, 0); 

  // Copy the message to the send buffer
  uint16_t len = mavlink_msg_to_send_buffer(buf, &msg);
  // Send the message (.write sends as bytes)
  Seria.write(buf, len);
}



/************************************************************
* @brief Sends Integer representation of location, only for ijnternal use (do not call directly)
* @param lat: latitude, lon: longitude, alt: altitude, gps_alt: altitude above MSL, heading: heading
* @return void
*************************************************************/
       
void command_globalgps(int8_t system_id, int8_t component_id, int32_t upTime, float lat, float lon, float alt, float gps_alt, uint16_t heading) {

  int16_t velx = 0; //x speed
  int16_t vely = 0; //y speed
  int16_t velz = 0; //z speed


  // Initialize the required buffers
  mavlink_message_t msg;
  uint8_t buf[MAVLINK_MAX_PACKET_LEN];

  // Pack the message
  mavlink_msg_global_position_int_pack(system_id, component_id, &msg, upTime, lat * 10000000.0, lon * 10000000.0, gps_alt * 1000.0, alt * 1000.0, velx, vely, velz, heading);

  // Copy the message to the send buffer
  uint16_t len = mavlink_msg_to_send_buffer(buf, &msg);
  // Send the message (.write sends as bytes)
  Seria.write(buf, len);
}

Ten przyklad dziala...jedynie uart sobie dostosuj do potrzeb i mozesz przetestowac.. i pametaj o tym co mowilem...anteny to podstawa! lepsza dobra antena niz zwiekszenie mocy 10 razy...

[sosnus]

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 ?
 

Dnia 6.08.2021 o 11:56, farmaceuta napisał:

Jesli planujesz swoja aplikacje to moim zdaniem nie ma sensu sie w to pchac...

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.

[farmaceuta]

5 godzin temu, sosnus napisał:

1. ustawić prędkości przesyłu na jak najmniejsze

Chyba 19200 masz teraz...tak wiec na 9600 i nizej nie ma sensu...

 

5 godzin temu, sosnus napisał:

 w związku z tym mogą "siać" i zakłócać antenę?

Generalnie wszystko moze zaklocac...nawet nieekranowane przewody od odbiornika dzialaja jak anteny i smieci zbieraja...tymi serwami bym sie nie przejmowal a staral sie uciec jak najdalej od anteny rc...

 

5 godzin temu, sosnus napisał:

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

Dipol ma +/- 32-35cm...i to jest najczesciej uzywana antena na tej czestotliwosci...jest tez ta "vee" o ktorej wspomniales, dlugosci drutu te same z tym ze zakrzywione w "V" i jest to delikatnie kierunkowa antena...jesli masz odrobinke zdolnosci manualnych to bez problemu mozesz takie anteny zrobic sam na tych ktore masz teraz...wywalasz antene i zostawiasz konektor z kablem ,do masy i goracej zyly lutujesz osobno(!) druty o dlugosci +/- 163-164mm i gotowe...napewno beda lepsze niz to co masz teraz...w zadne skrocone bym sie nie bawil...wiem ze do drona bylyby najlepsze, ale  zasieg spadnie...dipole trzymasz pionowo masa w dol...to samo na maszynie...aa..miejsce lutowania mozesz oblac klejem na goraco zeby sie to pewnie trzymalo...(jako przewodu mozesz uzyc czego chcesz...Ja np. mam z linki stalowej okolo 1-1.5mm w izolacji...jest elastyczna itp...i takie tez najczezciej sprzedaja/robia...