diff --git a/.wordlist.txt b/.wordlist.txt index 3a1cb0ac6..267c41432 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -236,7 +236,6 @@ QuadKopters HiYOUNGER JHEMCU Flywoo -ATTO EL MX Ironman @@ -274,3 +273,55 @@ nano AIOs accelerometer openocd +unpowered +selectable +Unbricking +overvoltage +Heatsink +Schottky +MHz +Niklas +Voigt +Seba +kilobits +ctzsnooze +SteveCEvans +Pawe +Stefański +phobos +Olaussen +klutvott +JyeSmith +CrazyF +Mobula +SPH +microcontroller +Zepto +Atto +distro's +QGC +COMs +ethernet +FW +Hotspot +hotspot +PIO +stlink +PIO's +TX's +callout +Bardwell +Bolded +FHSS +Jye's +rx +Uncommented +WebSocket +txt +VSCode +mingw +sourceforge +crc +https +HD +dodecatillion diff --git a/docs/hardware/backpack/backpack-tx-setup.md b/docs/hardware/backpack/backpack-tx-setup.md index d97e48d7c..c6f2db36b 100644 --- a/docs/hardware/backpack/backpack-tx-setup.md +++ b/docs/hardware/backpack/backpack-tx-setup.md @@ -146,9 +146,9 @@ If you have set your Home Network SSID and Password, point your browser to http: The main banner will show you what kind of device it is and the firmware version that's flashed into it. -## Setup your VRx Backpack +## Setup your VRX Backpack -Proceed to the [VRx Backpack Setup](backpack-vrx-setup.md) section to setup your VRx Backpack, if desired. +Proceed to the [VRX Backpack Setup](backpack-vrx-setup.md) section to setup your VRX Backpack, if desired. ## Operation diff --git a/docs/hardware/backpack/backpack-vrx-setup.md b/docs/hardware/backpack/backpack-vrx-setup.md index 23ae7cc6f..584ce76c9 100644 --- a/docs/hardware/backpack/backpack-vrx-setup.md +++ b/docs/hardware/backpack/backpack-vrx-setup.md @@ -15,7 +15,7 @@ The VRX firmware you will flash into your Backpack Device will depend on what VR ### Flashing via WiFi (ESP-based ExpressLRS Receivers) -Power up your selected VRX Backpack device (connect 5v and gnd pads to any 5v power source). Let it go into WiFi Update mode (fast blinking LED) and load up the WiFi Update page. In the Address bar of your browser, add `?force=true` to ensure it will accept the VRX Backpack firmware. The resulting URL should read `http://10.0.0.1/?force=true` (if you connected via Access Point) or `http://elrs_rx.local/?force=true` (if your device has connected to your local WiFi network). +Power up your selected VRX Backpack device (connect 5v and GND pads to any 5v power source). Let it go into WiFi Update mode (fast blinking LED) and load up the WiFi Update page. In the Address bar of your browser, add `?force=true` to ensure it will accept the VRX Backpack firmware. The resulting URL should read `http://10.0.0.1/?force=true` (if you connected via Access Point) or `http://elrs_rx.local/?force=true` (if your device has connected to your local WiFi network). !!! note "Note" The `?force=true` is not needed for ESP-based receivers with factory firmware. It is only required if you have previously flashed the receiver and want to repurpose it as a VRX Backpack. diff --git a/docs/hardware/crystal-frequency-error.md b/docs/hardware/crystal-frequency-error.md index ea18a430a..935ab669b 100644 --- a/docs/hardware/crystal-frequency-error.md +++ b/docs/hardware/crystal-frequency-error.md @@ -69,7 +69,7 @@ For example, this might look like (which is safe to just copy-paste in general): #### Procedure - - Using the configurator and user defines, include the `-DDEBUG_FREQ_CORRECTION` define for **BOTH TX AND RX** builds of any version of ELRS past v3.0.0 (ie V3.0.0 RC2) + - Using the configurator and user defines, include the `-DDEBUG_FREQ_CORRECTION` define for **BOTH TX AND RX** builds of any version of ELRS past v3.0.0 (i.e. V3.0.0 RC2) - After loading the new firmware on both TX and RX, go to the telemetry screen in your model settings on the TX side. Note the "RSNR" value. This is the relative difference between your TX and RX clocks. - *The closer this value is to 0, the better!*. Negative means the RX clock is slower than TX, and positive means that it is faster. - +/- 20 ticks (~30 kHz offset) is nearly perfect. +/-60 ticks (~95 kHz) will still likely be completely fine, though not ideal. +/-70 ticks and further is marginal and might be fine, but you should be careful. diff --git a/docs/hardware/fan-mod.md b/docs/hardware/fan-mod.md index ff6017115..77f00e97a 100644 --- a/docs/hardware/fan-mod.md +++ b/docs/hardware/fan-mod.md @@ -27,7 +27,7 @@ Initially, this mod is brought to life by [Niklas Voigt](https://discordapp.com/ You need a **20x20mm** or **25x25mm** **fan** in **5V** version. Both sizes are supported. To secure the fan into the cover you can use **2x M2 screws**, a thread is already in the print. -U can solder the pins of the fan directly to the **5v port of the R9M** or use the [**Controllable Fan Mod**](#controllable-fan-mod) which can control the fan out of software (fan blows only at >250mw). +You can solder the pins of the fan directly to the **5v port of the R9M** or use the [**Controllable Fan Mod**](#controllable-fan-mod) which can control the fan out of software (fan blows only at >250mW). R9M Fan Mod Cover is built out of four Parts and a Sticker: @@ -41,13 +41,13 @@ R9M Fan Mod Cover is built out of four Parts and a Sticker: * [R9M-Fan-Case-Pins.stl](https://github.com/ExpressLRS/ExpressLRS-Hardware/raw/master/STL/R9M-Fan-Mod-Case/R9M-Fan-Case-Pins.stl) * [R9M-Fan-Case-XT30.stl](https://github.com/ExpressLRS/ExpressLRS-Hardware/raw/master/STL/R9M-Fan-Mod-Case/R9M-Fan-Case-XT30.stl) * [R9M-Fan-Case-Standoff.stl](https://github.com/ExpressLRS/ExpressLRS-Hardware/raw/master/STL/R9M-Fan-Mod-Case/R9M-Fan-Case-Standoff.stl) (2x) -* [R9M-ExpressLRS-900Mhz.pdf](https://github.com/ExpressLRS/ExpressLRS-Hardware/raw/master/STL/R9M-Fan-Mod-Case/R9M-ExpressLRS-900Mhz.pdf) +* [R9M-ExpressLRS-900MHz.pdf](https://github.com/ExpressLRS/ExpressLRS-Hardware/raw/master/STL/R9M-Fan-Mod-Case/R9M-ExpressLRS-900Mhz.pdf) or from [Thingiverse](https://www.thingiverse.com/thing:4829360) ## Controllable Fan Mod -Additionally to the fan, you'll need one NPN Transistor (e.g. `2N4401`) or N-Channel MOSFET (e.g. `BS170` has built-in Shotky-Diode) and a resistor (200-3k7) +Additionally to the fan, you'll need one NPN Transistor (e.g. `2N4401`) or N-Channel MOSFET (e.g. `BS170` has built-in Schottky-Diode) and a resistor (200-3k7)
@@ -74,7 +74,7 @@ The PB9 pad location on the R9M2019 module is a bit different. Please see the ph In addition to the [3D printed Cover](#download) & the [**Controllable Fan Mod**](#controllable-fan-mod) you'll need: * Fan + Heatsink `"2507 25MM 25x25x13MM Hydraulic bearing Graphics card Cooling fan with heat sink 5V 12V m.2 SSD Fan with 2pin"` -* Thermalpad 0.5mm `"1pc 100mmx100mmx0.5mm GPU Northbridge IC LED Chipset Heatsink Cooling Conductive Silicone Thermal Pad,100x100x0.5mm w/ 3.2W/M-K"` +* Thermal Pad 0.5mm `"1pc 100mmx100mmx0.5mm GPU Northbridge IC LED Chipset Heatsink Cooling Conductive Silicone Thermal Pad,100x100x0.5mm w/ 3.2W/M-K"` The screw heads are cut off to reduce height. @@ -113,4 +113,4 @@ If you don't know how to allow the 2W in the firmware, don't do this mod!🤦‍
-
\ No newline at end of file +
diff --git a/docs/hardware/inverter-mod.md b/docs/hardware/inverter-mod.md index ab7b3a612..e629e9d64 100644 --- a/docs/hardware/inverter-mod.md +++ b/docs/hardware/inverter-mod.md @@ -7,7 +7,7 @@ description: A short guide on how to add a resistor for the R9M ACCST Inverter M ## Overview -- To benefit from the higher bitrate of 400 kilobits per second using `OpenTX`/`EdgeTX` you need to **add a pullup resistor to the inverter** of the serial port on the R9M 2018🗻🆙 +- To benefit from the higher bitrate of 400 kilobits per second using `OpenTX`/`EdgeTX` you need to **add a pull-up resistor to the inverter** of the serial port on the R9M 2018🗻🆙 - Strongly suggested being done for anybody looking for higher than standard packet rates using `ExpressLRS` 🔮 ## Identification @@ -36,4 +36,4 @@ Some Radios/Transmitters will require the Inverter/[Crossfire Mod](https://blog. | QX7 | 115200 | Not Needed | Not Needed | Max Packet Rate supported is 250Hz | | Others | 400000+ | Not Needed | Required | TX16S, TX12, T16/T18, etc | -`ACCESS` radios don't need the Inverter/Crossfire mod. \ No newline at end of file +`ACCESS` radios don't need the Inverter/Crossfire mod. diff --git a/docs/hardware/spi-receivers.md b/docs/hardware/spi-receivers.md index ba0aab28e..afcde17ec 100644 --- a/docs/hardware/spi-receivers.md +++ b/docs/hardware/spi-receivers.md @@ -8,12 +8,12 @@ description: All-in-one Flight Controllers were released with ExpressLRS receive !!! note "Supported RF Modes" SPI receivers **DO NOT** support D(D250, D500), F(F500, F1000) and Full Res(100Hz Full Res, 333Hz Full Res) Modes (Packet Rates) and thus will not bind or sync with a TX module in any of these modes. -A few Flight Controllers and AIOs have been released with ExpressLRS receivers on-board using SPI instead of a regular UART. This means you can build a more compact and lightweight whoop or nano longrange rig without the need for an external receiver. More of these flight controllers are coming into stores. +A few Flight Controllers and AIOs have been released with ExpressLRS receivers on-board using SPI instead of a regular UART. This means you can build a more compact and lightweight whoop or nano long range rig without the need for an external receiver. More of these flight controllers are coming into stores. Because the ExpressLRS code is "baked-in" to the flight controller firmware instead of using a second microcontroller, these can not be updated the same way external UART-based receivers are updated. !!! info "NOTE" - You cannot use the ExpressLRS Configurator to update these FCs. You must update the flight controller software, eg Betaflight. + You cannot use the ExpressLRS Configurator to update these FCs. You must update the flight controller software, e.g. Betaflight. SPI receiver compatibility with ExpressLRS v3.x *requires* your flight controller be flashed with [Betaflight 4.4](https://github.com/betaflight/betaflight/releases/tag/4.4.0). If you are running [Betaflight 4.3.0](https://github.com/betaflight/betaflight/releases/tag/4.3.0) or [Betaflight 4.3.1](https://github.com/betaflight/betaflight/releases/tag/4.3.1), your receiver will only work with ExpressLRS v2.x. Please update to Betaflight 4.4 for ExpressLRS v3.x compatibility. @@ -22,8 +22,8 @@ In preparation for updating, you should save a copy of your `diff all` dump. Sim Using the latest [Betaflight Configurator](https://github.com/betaflight/betaflight-configurator/releases), navigate into `Firmware Flasher` and select the latest [Betaflight release](https://github.com/betaflight/betaflight/releases/tag/4.4.0-RC2). Depending on your AIO board, the target will differ: -* Happymodel AIO: CRAZYBEEF4SX1280 -* BetaFPV AIO: BETAFPVF4SX1280 +* Happymodel AIO: `CRAZYBEEF4SX1280` +* BetaFPV AIO: `BETAFPVF4SX1280` * SPRacing SPH7RF: Coming soon! If your Flight Controller model is not in the list above, consult your Flight Controller manufacturer for details. @@ -117,4 +117,4 @@ The SPI ExpressLRS implementation would not have been possible without the work - Dominic Clifton ([@hydra](https://github.com/hydra)) - Hans Christian Olaussen ([@klutvott123](https://github.com/klutvott123)) - Steve Evans ([@SteveCEvans](https://github.com/SteveCEvans)) -- Ctzsnooze ([@ctzsnooze](https://github.com/ctzsnooze)) +- ctzsnooze ([@ctzsnooze](https://github.com/ctzsnooze)) diff --git a/docs/quick-start/ardupilot-setup.md b/docs/quick-start/ardupilot-setup.md index b2e551947..c3081ea08 100644 --- a/docs/quick-start/ardupilot-setup.md +++ b/docs/quick-start/ardupilot-setup.md @@ -1,25 +1,25 @@ --- template: main.html -description: ExpressLRS can be used with Ardupilot! This guide got you covered with the correct Ardupilot Parameters. +description: ExpressLRS can be used with ArduPilot! This guide got you covered with the correct ArduPilot Parameters. --- ![Setup-Banner](https://github.com/ExpressLRS/ExpressLRS-Hardware/raw/master/img/quick-start.png) -## Ardupilot Serial Setup +## ArduPilot Serial Setup -Ardupilot Firmware must be 4.1 or higher to run CRSF protocol. -As with any serial-based receiver, you need to attach the TX/RX pads to a UART on your flight controller, then enable Serial RX in the corresponding UART in Ardupilot. +ArduPilot Firmware must be 4.1 or higher to run CRSF protocol. +As with any serial-based receiver, you need to attach the TX/RX pads to a UART on your flight controller, then enable Serial RX in the corresponding UART in ArduPilot. In mission planner, you will need to go to the ```config tab -> parameter tree``` ``` SERIALx_PROTOCOL = 23 (RCIN) RSSI_TYPE = 3 (ReceiverProtocol) ``` -our packet rate is different than CRSF packet rate, and Ardupilot will keep on reporting the mismatch, but recently they have an option to suppress the report. Currently Ardupilot provide a way to suppress this notification with the parameter below. (this will not cause any effect to RC link or telemetry Link.) +our packet rate is different than CRSF packet rate, and ArduPilot will keep on reporting the mismatch, but recently they have an option to suppress the report. Currently ArduPilot provide a way to suppress this notification with the parameter below. (this will not cause any effect to RC link or telemetry Link.) ``` RC_OPTIONS turn on Bit 9th which is "Suppress CRSF mode/rate message for ELRS systems". ``` -Once you have set the parameter above, power-cycle the flight controller by disconnecting and reconnecting your battery and USB. Ardupilot should automatically run with ELRS, but if it fails, set ``RC_PROTOCOL`` parameter 9th bit to 1 (CRSF option) +Once you have set the parameter above, power-cycle the flight controller by disconnecting and reconnecting your battery and USB. ArduPilot should automatically run with ELRS, but if it fails, set ``RC_PROTOCOL`` parameter 9th bit to 1 (CRSF option) and set the other parameter as below: ``` SERIALx_PROTOCOL = 23 (RCIN) @@ -27,13 +27,13 @@ SERIALx_BAUD = 115 RSSI_TYPE = 3 (ReceiverProtocol) ``` -## Ardupilot Flight Modes -Ardupilot default flight modes channel is channel 8, but ELRS 8 position channel is on channel 12 (in hybrid switch mode). you will need to set your handset to use channel 12 as flight modes and set Ardupilot parameter: +## ArduPilot Flight Modes +ArduPilot default flight modes channel is channel 8, but ELRS 8 position channel is on channel 12 (in hybrid switch mode). you will need to set your handset to use channel 12 as flight modes and set ArduPilot parameter: ``` FLTMODE_CH=12 ``` if you are using Wide Switch mode (only available in ELRS V2 and above), you can use any channel for your 8 flight mode selection (beside channel 15 which is LQ and channel 16 which is RSSI). -## Ardupilot RSSI and Link Quality +## ArduPilot RSSI and Link Quality To get RSSI and LQ shown in OSD (in %) set: ``` RSSI_TYPE = 3 (ReceiverProtocol) diff --git a/docs/software/obsolete-defines.md b/docs/software/obsolete-defines.md index f8c49dba6..8dcadabe2 100644 --- a/docs/software/obsolete-defines.md +++ b/docs/software/obsolete-defines.md @@ -7,7 +7,7 @@ template: main.html !!! note This page contains old user_defines.txt that have been removed or superseded by new defines. -New items should be added to the top of the list so the last entry here is the oldest. The order of each entry should be [code]definename[/code] followed by the original text of the documentation, ending with a separate paragraph "**REMOVED** [version] [replacement or reason for removal]". +New items should be added to the top of the list so the last entry here is the oldest. The order of each entry should be `[code]definename[/code]` followed by the original text of the documentation, ending with a separate paragraph "**REMOVED** [version] [replacement or reason for removal]". ## Obsolete Defines @@ -44,7 +44,7 @@ These features enable **lower latency** 🏃‍♂️ and **offset** from the Op Both require [OpenTX `2.3.12`](https://www.open-tx.org/) or above. To install it, you will have to use OpenTX companion application. -Deviation radio users such as those with the T8SGv2/v3 should disable this feature. +Deviation radio users such as those with the T8SG v2/v3 should disable this feature. You can also use [EdgeTX](https://github.com/EdgeTX/edgetx). diff --git a/docs/software/open-ocd.md b/docs/software/open-ocd.md index 6c2e2b8f9..a4aa1799b 100644 --- a/docs/software/open-ocd.md +++ b/docs/software/open-ocd.md @@ -13,7 +13,7 @@ If you are using Linux then you can't use the ST-LINK utility from st.com. But f a. For R9mm/Mini `openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c 'init; reset halt; stm32f1x unlock 0; reset run; shutdown'` - b. For Ghost Átto/Zepto `openocd -f interface/stlink-v2.cfg -f target/stm32f3x.cfg -c 'init; reset halt; stm32f3x unlock 0; flash protect 0 0 last off; reset halt; exit'` + b. For Ghost Atto/Zepto `openocd -f interface/stlink-v2.cfg -f target/stm32f3x.cfg -c 'init; reset halt; stm32f3x unlock 0; flash protect 0 0 last off; reset halt; exit'` 3. Restart your device so the disabled readout protection can take effect. 4. Now you can proceed with flashing your receiver. This may work on other devices or it might not. diff --git a/docs/software/switch-config.md b/docs/software/switch-config.md index 6ae900d69..2f380a6c7 100644 --- a/docs/software/switch-config.md +++ b/docs/software/switch-config.md @@ -83,7 +83,7 @@ For the remaining 7 switches (Chan 6 thru 12 / AUX 2 thru AUX 8), only one swit In **Hybrid** mode, AUX2-AUX7 / Chan6-11 are 3-bit and can be used as either 2-position, 3-position, or 6-position switches or selector buttons. These are mapped to a PWM of 1000us to 2000us. -|2-pos
Switch |3-pos
Switch |6-pos
Switch | Approx. Channel
Input PWM (us) | Channel
Output (us) | Ardupilot Mode +|2-pos
Switch |3-pos
Switch |6-pos
Switch | Approx. Channel
Input PWM (us) | Channel
Output (us) | ArduPilot Mode |:--: | :--: | :--: | :--: | :--: | -- |1|1|1|988 | 1000 | Mode1 (up position for 2-pos / 3-pos) |||2|1192 | 1275 | Mode2 @@ -102,7 +102,7 @@ In **Hybrid** mode, AUX8 / Chan12 is 4-bit / 16-position and is mapped to the PW In **Wide** mode, AUX2-AUX8 / Chan6-12 are 6-bit / 64-position for telemetry ratios of 1:2 and 1:4. For all other telemetry ratios, these 7 switches are 7-bit / 128-position. It takes 8 packets to send the complete set of switches before cycling back to AUX2 (one more than **Hybrid**). **Wide** uses the 8th slot to transmit extra data to the receiver, including the current transmitter power. This is the only switch mode which can show the transmitter power `TPwr` on the flight controller's OSD. These behave more like traditional channels although with lower precision. You can tell you're operating in **Wide** mode when a switch in the middle position shows up as 1503 instead of 1500. -If using Ardupilot in **Wide** mode you will see that the channel outputs don't line up very well with the standard -100% (988us) to +100% (2012us) output range in EdgeTX / OpenTX when using a 6-position selector as input. Both the first two and the last two positions get binned into Mode 1 and Mode 6 respectively. To get the full 6 Ardupilot modes, go to the Outputs page on the OpenTX model setup and set the min / max for the channels to -75% / +75%. +If using ArduPilot in **Wide** mode you will see that the channel outputs don't line up very well with the standard -100% (988us) to +100% (2012us) output range in EdgeTX / OpenTX when using a 6-position selector as input. Both the first two and the last two positions get binned into Mode 1 and Mode 6 respectively. To get the full 6 ArduPilot modes, go to the Outputs page on the OpenTX model setup and set the min / max for the channels to -75% / +75%. ### Full Resolution Switch Configuration Modes :new: @@ -168,4 +168,4 @@ All of these 10-bit or 1024 positions are mapped to PWM 885us to 2115us (1 bit = ??? Note "Every time I change switch mode in Lua, it changes back! Is my transmitter broken?" If the Lua loads then you know its communicating with your transmitter. However, the switch mode can only be changed when a receiver is not connected and makes it appear as if the changes are not saving. This is done to ensure consistency between the RX's and TX's interpretation of the switch data being actively transmitted. This is a safeguard. Power down your receiver, wait for the "Telemetry Lost" callout, and the switch mode change will stick / save. The receiver will talk to the transmitted when it is powered up to handshake on the new settings. - \ No newline at end of file + diff --git a/docs/software/testing/crc-testing.md b/docs/software/testing/crc-testing.md index c01270ece..1262838bd 100644 --- a/docs/software/testing/crc-testing.md +++ b/docs/software/testing/crc-testing.md @@ -8,7 +8,7 @@ template: main.html After performing CRC tests using the CRC-13 it was found that CRC includes parity checking so adding a separate parity check was wasteful. CRC checking has now been updated to 14-bit. -The following tests were performed using the new CRC-14 bit implementation with a polynomial of 0x372B, which gives a hamming distance of 6 in a 57-bit range. What this means is that it can detect up to 5 randomly flipped bits of a message that is 57 bits long. +The following tests were performed using the new CRC-14 bit implementation with a polynomial of `0x372B`, which gives a hamming distance of 6 in a 57-bit range. What this means is that it can detect up to 5 randomly flipped bits of a message that is 57 bits long. Three stress tests have been performed on the 50-bit data with CRC-14. The tests create random data in 7 bytes (the first byte only has the lower 2 bits set) and then perform random bit flipping based on three styles. @@ -125,7 +125,7 @@ Also this is where the built-in parity shows up as it detects the odd numbered b ## OTA Testing -A 5hr OTA soak test was done at RSSI -108dBm (2.4GHz, 500Hz) and branch https://github.com/ExpressLRS/ExpressLRS/commit/e3ddcc. RC data bytes were hard coded 0xAA and checked for CRC14 pass/fail, and the number of bits flipped counted. +A 5hr OTA soak test was done at RSSI -108dBm (2.4GHz, 500Hz) and branch [`counting-flipped-bits@e3ddcc`](https://github.com/ExpressLRS/ExpressLRS/commit/e3ddcc). RC data bytes were hard coded `0xAA` and checked for CRC14 pass/fail, and the number of bits flipped counted. The below table columns are the number of bits flipped, crc passed tally, crc failed tally. Where passed means a bad packet that passes the CRC check and would accepted by the RX. On the `0` row, `Passed` is good, `Failed` is where the data is good, but the CRC itself was changed by bit-flips. ``` @@ -215,4 +215,4 @@ CRC | Passed | Failed 37 | 0 | 0 38 | 0 | 0 39 | 0 | 0 -``` \ No newline at end of file +``` diff --git a/docs/software/testing/unit-testing.md b/docs/software/testing/unit-testing.md index daeacef5b..d15fa11b1 100644 --- a/docs/software/testing/unit-testing.md +++ b/docs/software/testing/unit-testing.md @@ -6,7 +6,7 @@ template: main.html ## Tools -Assuming you have Visual Studio Code and platformIO installed +Assuming you have Visual Studio Code and PlatformIO installed ## Windows Prerequisite @@ -19,4 +19,4 @@ Assuming you have Visual Studio Code and platformIO installed * In VSCode with the ExpressLRS project open, click on the `New Terminal` button in the status bar * Ensure the native platform is installed by entering `pio platform install native` in the terminal window. * Now you can enter `pio test -e native` to run the tests. -* It is also possible to use the pio module and select native/Advanced/Test in the target selection list. \ No newline at end of file +* It is also possible to use the PlatformIO module and select Native/Advanced/Test in the target selection list. diff --git a/docs/software/updating/betaflight-passthrough.md b/docs/software/updating/betaflight-passthrough.md index 40ee7c84f..259161b6b 100644 --- a/docs/software/updating/betaflight-passthrough.md +++ b/docs/software/updating/betaflight-passthrough.md @@ -33,16 +33,16 @@ Since 1.0.0, ESP receivers can be updated via passthrough without using the boot - Sometimes the boot jumper or button must be used while powering up the receiver. -## Ardupilot Instructions (community contribution, untested) +## ArduPilot Instructions (community contribution, untested) - Connect the autopilot to a PC using a USB cable and connect with a Ground Station (i.e. Mission Planner, QGC, etc). -- Set SERIAL_PASSTIMO to a length of time (in seconds) that gives you enough time to connect with the sensor’s configuration software. 30 to 60 seconds is a good choice -- Set SERIAL_PASS2 to the number of the serial port connected to the sensor. I.e. “2” if the sensor is connected to Telem2/Serial2. -- Be sure to set each port’s baud rate appropriately using the SERIALx_BAUD parameter. The rates may be different for each port. ArduPilot will do the buffering. +- Set `SERIAL_PASSTIMO` to a length of time (in seconds) that gives you enough time to connect with the sensor’s configuration software. 30 to 60 seconds is a good choice +- Set `SERIAL_PASS2` to the number of the serial port connected to the sensor. I.e. “2” if the sensor is connected to Telem2/Serial2. +- Be sure to set each port’s baud rate appropriately using the `SERIALx_BAUD` parameter. The rates may be different for each port. ArduPilot will do the buffering. - Press the “Disconnect” button on the ground station but leave the USB cable from the PC to the autopilot connected. - Open the sensor’s configuration software and connect to the autopilot’s COM port. If all goes well the configuration software should work as it does when the PC is directly connected to the sensor - If the configuration fails to connect there are some things to try: - Some configuration software will not allow connecting to the autopilot’s COM port by default but may have an option to display all available COM ports - If no serial messages are received from the PC the timeout will expire and SERIAL_PASS2 will revert to -1 - You can also refer to the [Ardupilot official docs](https://ardupilot.org/plane/docs/common-serial-passthrough.html) for serial passthrough. + You can also refer to the [ArduPilot official docs](https://ardupilot.org/plane/docs/common-serial-passthrough.html) for serial passthrough. diff --git a/docs/software/updating/wifi-updating.md b/docs/software/updating/wifi-updating.md index 29cdab33c..a7de54ce5 100644 --- a/docs/software/updating/wifi-updating.md +++ b/docs/software/updating/wifi-updating.md @@ -17,7 +17,7 @@ Put your device in WiFi Updating mode. For TX modules, this is accomplished usin Connect to the hotspot that the device has created. For TX modules, this hotspot should show up as **ExpressLRS TX** while for receivers, the hotspot will have a name such as **ExpressLRS RX**. They have the same password: `expresslrs`. ??? Warning "Updating on Phones (click/tap to expand)" - In case your computer does not have wifi capabilities, you can use a wifi capable smartphone as well. Most phones will display a notification after a successfull connection. This is because the phone does not recognize an internet connection. It is recommended to acknowledge this notification because the phone might disconnect again. + In case your computer does not have WiFi capabilities, you can use a WiFi capable smartphone as well. Most phones will display a notification after a successful connection. This is because the phone does not recognize an internet connection. It is recommended to acknowledge this notification because the phone might disconnect again. On iOS, the WiFi Update Page may open immediately. You can close it via the "Cancel" button on the top right and choose "Use without internet"