Páran már tapasztalhattuk, hogy amióta a Betaflight nevű bughalmaz konfigurációs felülete 3.2-re frissült, módszeresen elcseszi azon repvezérlők beállításait, amelyek 3.1-nél öregebb Betaflightot futtatnak, ezáltal hozva agyérgörcsöt és szemrángást azokra, akik nem időmilliomosok, például:
Hogy hugyozná szemen magát aki szerint jó ötlet volt kierőltetni a 3.2-es Bugflight configuratort!
Most ez miatt ugrott az esti röptetésem, mert az a szar szó szerint lenullázta a receiver barokat a 3.0.1-es Babyhawkon.
Régi BF configurator sem oldotta meg, csak a 3.2-es felrakása, amihez persze életre kellett bírnom a szájbavert DFU módot a hazudós Zadig-on keresztül.
És aljas meglepetésként a 3.2 felrakása után felpörögtek a motorok egy fél másodpercre! Ennek kimondottan örültem!
A fenti idézetben benne is van a megoldás, frissíteni kell a repvezérlőn lévő firmware-t és minden jó lesz. Na de mi is az a szájbavert DFU mód és a hazudós Zadig, amire nekünk szükségünk lesz? Nem elég csak csatlakoztatni a repvezérlőt az USB-re és felrakni a legújabb Betaflight-ot? Bizony nem! Legalább is az újabb repvezérlőknél.
A különbség a régebbi és újabb repvezérlők között
A Betaflight, Cleanflight és iNAV olyan repvezérlőkön fut, amelyek STM32 mikrokontrollert használnak. A régebbi repvezérlők nem közvetlenül csatlakoztak a pécénkhez az USB porton keresztül, hanem egy soros porton és egy soros port - > USB átalakítón keresztül. Ha ez a soros port az UART1 volt, amire történetesen a repvezérlőn pedig egy GPS-t kötöttünk, akkor bizony azt le kellett húzni, akárhányszor a PC-re akartuk csatlakoztatni a repvezérlőt. Ekkor támadt valakinek az a csodás ötlete, ha már minden STM32 natívan támogatja az USB-t, miért ne lehetne közvetlenül azon keresztül csatakoztatni a PC-hez. Az ötletet tett követte és az SP F3 EVO-val kezdve nem a limitált számú soros porton csatlakozott a repvezérlő a PC-re, hanem az erre dedikált porton. A Ports lapon ez a port a VCP, a soros portok pedig az UART-ok.
Firmware frissítés DFU módban
Egyetlenegy hátránya van a dedikált USB portnak, hogy a firmware frissítés nem megy közvetlenül az USB proton keresztül, előtte a repvezérlőnket DFU módba kell juttatni. Ez kétféle módon történhet:
1. A repvezérlőn összezárjuk a boot pineket vagy lenyomjuk a boot gombot és bedugjuk a repvezérlő USB portjába a kábelt, hasonlóan ahhoz, amikor bootloader módba akartuk juttatni a régebbi repvezérlőt. Ez egyszerűen hangzik, de olyan mütyürnél mint az Emax Femto, ha egyedül csináljuk előbb verjük szét a falon, minthogy ez sikerülne. Persze össze is forraszthatjuk a boot pineket, de egy kész gépnél hadd ne mondjam mennyire macerás. Az egyik Omnibusomon meg egyszerűen kontakthibás a boot gomb.
Na, ezt nyomogathatjuk napestig, NEM fog bootloader módba menni a masina
2. Csatlakozunk a repvezérlőhöz a hagyományos módon, átkattintunk a CLI lapra és a parancssorba beírjuk DFU és Entert ütünk. Ennyi!
Ekkor a Windowsnak észlelnie kéne és el kéne kezdenie felkutatni a szükséges drivert. Ehhez csatlakoznia kell az internethez és nem szabad, hogy le legyen tiltva a Windows update é a wsus szolgáltatás.
Ha feltelepült a DFU driver, cserélhetjük is le. Töltsük le a Zadig-ot, majd indítsuk rendszergazdaként.
A zadig weboldalán azt állítják, hogy nem kell rendszergazdaként indítani, mert úgyis felugrik az UAC ablak, és elég leokéznunk, hogy rendszergazdaként induljon és minden menni fog. A faszt nem kell! Ha egyszerű júzerként indítjuk, legalábbis Windows 7-en, akkor negyed órán át fog molyolni, majd közli, hogy nem sikerült telepíteni a drivert!
Az Options menüben jelöljük ki a list all devices-ot. A leugró menüben az STM32 Bootloadernek kell szerepelnie. Ha az lenne, hogy F3evo, vagy OmnibusF4, akkor valamit elcsesztünk és kezdhetjük elölről a boot pin nyomkodását, etc.
Ellenőrizzük, hogy a driver mező nem üres-e, mellette válasszuk ki a WinUSB v6.1.xxx-et és kattintsunk a Replace Driver gombra. Maximum egy percen belül végeznie kéne a gépnek.
Intermezzo
Ha az STM32 Bootloadernél a driver mező üres, jobb oldalt pedig az Install Driver szerepel, akkor a Windows nem installálta fel a lecserélendő drivert.
Mehetünk az Eszközkezelőbe törölni, majd ellenőrizni, hogy a Windows update és a WSUS fut-e.
Sajnos első kézből van tapasztalatom. Történt ugyanis, hogy mivel mobilnetről voltam, kikapcsoltam a windows update-et, mert nem vagyok krőzus és ezen kívül a wsus-t is, hogy ne tekerje az egyik procimagot 100%-on, ha úgy tartja kedve. Mikor már három órája nem mászott fel az a szájbavert driver magától, eszmbe jutott, hátha ez a hiba. Engedélyeztem a wsus-t, erre az bekapcsolta a windows update-et, ami a DFU driver mellé mindjárt le is kapott olyan fél giga update-et. Mondtam hogy mobilnetről voltam? Lyuly!
No, ha felmászott a DFU, zárjuk be a Chrome-ot, ha nyitva lenne, indítsuk a Betaflightot vagy az iNAV-ot és rakhatjuk is fel a hőn vágyott friss, ropogós és valószínűleg faszán bugos firmwaret. A jobb felső sarokban nem COM port hanem a DFU fog szerepelni. Vigyázzunk, hogy jó traget-ot tegyünk fel, mivel ha rosszat teszünk fel, akkor az újraflasheléshez csak a boot pinnel bohóckodás marad. Emax Femto-nál ez az F3 EVO, Omnibus F4 V2 pro nál Betaflight alatt az OmnibusF4SD, iNAV alatt pedig az OmnibusF4PRO.
Betaflight + SP F3 EVO-nál a Load Firmware Online-ra kattintás majd a flashelést követően megjavultak a receiver barok.
iNAV-nál pedig végre felmászott a hőn áhított iNAV az Omnibusra, hogy végre az S800 csupaszárny röpcsiben teljesíthessen szolgálatot:
És még valami, amiről nem tudom hogy bug-e vagy fícsör - F4 lapoknál ne használjuk a "Full Chip Erase" opciót, mert megakadhat a flashelés. A beállításokat sikeres flashelés után a "defaults" CLI paranccsal tudjuk alaphelyzetbe állítani.
És még valami 2 - elvileg, ha be van kattintva az egyik soros porton az MSP, akkor egy FTDI adapterrel simán felflashelhetnénk a repvezérlőt, és nem kéne DFU módba juttatni. Nekem ez az Omnibus F4-nél nem sikerült és ahogy látom, másoknak sem jött össze F4 lapoknál.
Ha tetszett a bejegyzés dobj egy lájkot YouTubeon vagy Facebookon! Köszi!