betaflight / betaflight

Open Source Flight Controller Firmware
GNU General Public License v3.0
8.06k stars 2.87k forks source link

ExpressLRS over SPI - sx1280 and sx1276 support #10788

Closed phobos- closed 2 years ago

phobos- commented 2 years ago

Fixes #10615

Support

If you have support questions, please feel free to join Discord, me (Phobos#4328@discord) or someone else can help you there. -- https://discord.gg/dS6ReFY

Intro

This is an initial implementation of SPI ExpressLRS receiver. It serves the purpose of integrating ExpressLRS into whoop aio boards with short to medium range. It has an additional benefit of not using crsf protocol and improving overall end to end latency. Huge thanks to @githubDLG @AlessandroAU @JyeSmith @wvarty @hydra and others for the hardware and help with debugging, testing and code review.

Binding

There are two ways to bind the receiver:

  1. Standard bind procedure. Using your favourite method (configurator button / cli bind_rx command / physical button on the board / setting expresslrs_uid = 0, saving and rebooting the board) put the rx into bind mode. Enter elrs lua in your handset and press the bind button. RX and TX should be now bound. Please mind the order, RX first, TX second. How to bind tutorial (thanks to @JyeSmith ): https://www.youtube.com/watch?v=U2sxqx2oT4k
  2. Passphrase. Set passphrase in the TX and flash to your ExpressLRS transmitter module. Go to below page, input your passphrase and copy cli commands: https://busheezy.github.io/elrs-binding-phrase-to-bytes/ Go to betaflight cli and paste the commands. RX and TX should be now bound.

Be sure to set the correct domain for your RX - ISM2400 for 2.4G and corresponding frequency domain of your choice for 900/433MHz. Configuration like RF rate (500Hz-50Hz for 2.4g and 200-25Hz for 900Mhz), telemetry rate, hybrid/standard switches is propagated automatically from the TX to the RX. There is no need to configure it. Give some extra time when connecting for the first time after changing the config in your handset in order to propagate the configuration to the rx and save it to eeprom. All subsequent connections should then be very quick. RX operates in 'lock on first connection' mode, so in order to switch to a different RF rate you have to power cycle the RX. It is generally recommended to power up the TX before the RX in order to avoid cycling through all RF rates on the RX and get the connection faster.

Configuration

Configuration parameters:

expresslrs_uid = 0,0,0,0,0
Array length: 6
Default value: 0,0,0,0,0,0

expresslrs_domain = ISM2400
Allowed values: AU433, AU915, EU433, EU868, FCC915, IN866, ISM2400
Default value: AU433

expresslrs_rate_index = 0
Allowed range: 0 - 3

expresslrs_switch_mode = WIDE
Allowed values: HYBRID, WIDE
Default value: HYBRID

expresslrs_model_id = 255
Allowed range: 0 - 255

YouTube Links

How to bind (thanks to @JyeSmith ): https://www.youtube.com/watch?v=U2sxqx2oT4k

Range test results with Happymodel hardware: https://www.youtube.com/watch?v=bSM4ypPrSB4 https://www.youtube.com/watch?v=-bHF6Vs7f9I https://www.youtube.com/watch?v=IgBrWlz1EiY https://www.youtube.com/watch?v=dwom_ZqKxpI

Known issues / limitations

Future development to be done in separate PRs in order of importance:

Latest firmware

v2.0.0 firmware for CRAZYBEEF4SX1280: betaflight_4.3.0_CRAZYBEEF4SX1280_eb873308c.zip

hydra commented 2 years ago

The SPRacingH7RF FC uses a slightly earlier version of this code which is flight tested on an H730 CPU.

See also:

DusKing1 commented 2 years ago

You should also build G4 unified target

hydra commented 2 years ago

@Phobos did you consider putting the info at the top of this PR into Markdown files in the docs/ folder?

Can I request that once this is merged that the Wiki and other documentation is updated with at least the binding instructions from above.

dkuchay commented 2 years ago

Working on AIO ELRS from Happymodel with happymodels tx unit in a tx16s. Used above image for betaflight local fw upgrade. Went with nightly version of betaflight. Had to get their (happymodels) diff file for this board to restore hardware associations. Also had to reboot TX (rebooted radio), to show bind at end of the above instructions. Just flew, works wonderfully.

blockfeed commented 2 years ago

I built a hex of Betaflight for the HM 2.4G AIO ELRS FC using commit 04ab491 and have been running it daily since the evening of 6/13/2021. I also used the Happymodel diff to configure the hardware-specific portions. I was able to re-bind using expresslrs_uid (I'm using a binding passphrase). So far no issues and everything appears to function properly.

frankjannis commented 2 years ago

Will there be the possibility to use other packet rates in the future? Very impressed with the current performance but 500 Hz is pretty much overkill for me and additional range would be handy... Thanks for your work!

Ps: Does anyone have experience with flashing the Happymodel 2.4 GHz AIO? Is it possible at all?

AlessandroAU commented 2 years ago

Will there be the possibility to use other packet rates in the future? Very impressed with the current performance but 500 Hz is pretty much overkill for me and additional range would be handy... Thanks for your work!

Ps: Does anyone have experience with flashing the Happymodel 2.4 GHz AIO? Is it possible at all?

Yes, 50hz to 500hz already works, and yes this PR is what you flash to the HM AIO board.

phobos- commented 2 years ago

@hydra I will open a separate PR with the documentation once this PR gets merged. @frankjannis You can use any rate that is supported by expresslrs, from 500Hz down to 50Hz. Happymodel 2.4Ghz AIo is running this code and can be flashed with STM32F411 target + below dump: http://www.happymodel.cn/index.php/2021/05/18/betaflight-firmware-diff-document-elrs-lua-es24tx-firmware-for-happymodel-elrs-f4-2g4/ It is all well explained there. Good luck!

Izlud commented 2 years ago

@frankjannis You can use any rate that is supported by expresslrs, from 500Hz down to 50Hz. Happymodel 2.4Ghz AIo is running this code and can be flashed with STM32F411 target + below dump: http://www.happymodel.cn/index.php/2021/05/18/betaflight-firmware-diff-document-elrs-lua-es24tx-firmware-for-happymodel-elrs-f4-2g4/ It is all well explained there. Good luck!

I have followed the tutorial on HM website, but I have an issue with the GYRO. In the betaflight sensor tab, nothing is happening when I move the board. I can't arm the quad I got the CALIB error. I tryed increasing the CALIB time out, The quad arms, but then is unflyable.

vodka-bears commented 2 years ago

@Izlud sounds like a defective gyro. Or an earthquake.

AlessandroAU commented 2 years ago

You need cut and paste the stock diff back into the CLI

Izlud commented 2 years ago

You need cut and paste the stock diff back into the CLI

I used the diff from the tutorial on the HM website.

Betaflight / STM32F411 (S411) 4.3.0 May 15 2021 / 10:33:08 (norevision) MSP API: 1.44

ERROR IN diff: NO CONFIG FOUND

start the command batch

batch start

board_name CRAZYBEEF4SX1280 manufacturer_id HAMO

AlessandroAU commented 2 years ago

Then type save + enter?

Izlud commented 2 years ago

Then type save + enter?

yes.

It is worth noting, I tryed to flash the receiver with ELRS tool using the betaflight pass through. Maybe I messed something up doing this.

Izlud commented 2 years ago

The accelerometer has very bas noise. The gyro is flat.

I saw someone with a similar problem here : https://github.com/betaflight/betaflight/issues/9994

How did he delete flashdisk ?

deadgyro

vodka-bears commented 2 years ago

@Izlud please proceed to the ExpressLRS discord server

Izlud commented 2 years ago

@Izlud please proceed to the ExpressLRS discord server

I have asked there about my issue. We counldn't fix it. Then they redirected my to @phobos-

It is a brand new board. But I didn't test the gyro when i got it. It can be an hardware problem

AlessandroAU commented 2 years ago

BETAFPV is also about to release similar hardware. Would be nice to get this PR moving :) image

jeffpearce commented 2 years ago

This is working flawlessly on 3 HM boards, but with RC versions of elrs. Looking forward to seeing this merged so I can upgrade to the final elrs

ctzsnooze commented 2 years ago

I think something in #10705 may disagree with this PR.

I get these build errors after that was merged, but not before:

./src/main/drivers/rx/rx_spi.c:190:5: warning: implicit declaration of function 'ENABLE_RX' [-Wimplicit-function-declaration]
  190 |     ENABLE_RX();
./src/main/drivers/rx/rx_spi.c:191:5: warning: implicit declaration of function 'spiBusRawTransfer' [-Wimplicit-function-declaration]
  191 |     spiBusRawTransfer(busdev, data, data, length);
./src/main/drivers/rx/rx_spi.c:191:23: error: 'busdev' undeclared (first use in this function)
  191 |     spiBusRawTransfer(busdev, data, data, length);
./src/main/drivers/rx/rx_spi.c:191:23: note: each undeclared identifier is reported only once for each function it appears in
./src/main/drivers/rx/rx_spi.c:192:5: warning: implicit declaration of function 'DISABLE_RX' [-Wimplicit-function-declaration]
  192 |     DISABLE_RX();
hydra commented 2 years ago

I have a fix for that prepared and tested today. I messaged @phobos- with it via discord a few days ago.  I'll see if I can do a PR to @phobos-'s branch later on.

hydra commented 2 years ago

@phobos- done!

See this PR to your branch:

https://github.com/phobos-/betaflight/pull/1

or git apply this patch:

From e9213b8be97f1cc964354984d2d20cad86814558 Mon Sep 17 00:00:00 2001
From: Dominic Clifton <dominic.clifton@cleanflight.com>
Date: Wed, 28 Jul 2021 18:17:39 +0200
Subject: [PATCH] ExpressLRS updates for new SPI API.

---
 src/main/drivers/rx/rx_spi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/main/drivers/rx/rx_spi.c b/src/main/drivers/rx/rx_spi.c
index 00219b629a..c02be70be2 100644
--- a/src/main/drivers/rx/rx_spi.c
+++ b/src/main/drivers/rx/rx_spi.c
@@ -187,9 +187,7 @@ timeUs_t rxSpiGetLastExtiTimeUs(void)

 void rxSpiTransferCommandMulti(uint8_t *data, uint8_t length)
 {
-    ENABLE_RX();
-    spiBusRawTransfer(busdev, data, data, length);
-    DISABLE_RX();
+    spiReadWriteBuf(dev, data, data, length);
 }

 #endif
--
2.28.0

Tested on SPRacingH7RF.

phobos- commented 2 years ago

@hydra thanks, merged. @Izlud it looks to me as a hardware problem unfortunately. Go to discord and send me a PM with your diff, I'll try to help.

hydra commented 2 years ago

This code still working fine, but PR #10573 breaks it. The link is lost when you arm if you have blackbox logging on SD card enabled or if you start logging after you arm.

See https://github.com/betaflight/betaflight/pull/10573#issuecomment-895921678

hydra commented 2 years ago

The RX code is frequently late. I hacked in this commit to bump the RX task to REALTIME and now it's never late, but mind you late reporting might also be wrong, but the LQ is pinned to 100 now.

https://github.com/spracing/betaflight/commit/a303f7cd4eecd8c9974c39785b8e7f8142f29750

Before:

Task list             rate/hz  max/us  avg/us maxload avgload  total/ms   late    run reqd/us
07 - (             RX)    500      48      22    2.9%    1.6%       833    311   2956      27

After:

Task list             rate/hz  max/us  avg/us maxload avgload  total/ms   late    run reqd/us
07 - (             RX)    492      96      24    5.2%    1.6%       606      0  24580       0

As noted via discord chat, there's no point having other tasks running on time if your RC link is gone.

Not suggesting this as a fix, but it illustrates the problem quite nicely.

AlessandroAU commented 2 years ago

Hi all (@SteveCEvans @hydra),

Just a comment about how ELRS works so we can be on the same page. I would very much like to see an ISR approach. ELRS is a little different to other control links in that on-air-time (duty cycle) is maximised. This gives the most favourable modulation parameters and hence range for a given packet rate. Other links only run at 50% duty or so, and therefore as long as the control logic is handled sometime in the latter half of the of frame interval all is well and the timing is not that critical.

With ELRS there is perhaps a 300-500us window where all the logic, processing and SPI transfers must happen. If the critical window is missed then the system might not hop in unison to a new frequency and the link will be lost. This is achieved using hwtimers to lock the two systems together.

Typically, the local hwtimer will stay locked to the remote one within +/-5us, even when LQ is poor. This is what gives ELRS exceptional stability. I will explain how this is achieved on the standalone RX to provide some background.

  1. There is a hardware timer running on both RX/TX. The TX side hwtimer is always free-running. On the RX side, it's triggered to begin when a SYNC type packet is received which details the exact spot in the RNG FHSS sequence the TX is at. The RX listens at the first frequency index and waits for this packet when there isn't a link.

  2. From then, whenever a packet is received, the timestamp of the ISR is compared to expected received time based on the internal hwtimer. This gives the instantaneous phase offset between the two timers.

  3. This phase offset is passed through a low-pass filter and used to immediately phase offset the next tick of the (local) hardware timer to correct it.

  4. Another bit of logic looks at whether the phase shifts have been mostly positive or negative and adjusts the base period of the hwtimer over a longer timescale. This drives the instantaneous phase offset to zero over around 5-15 seconds. This accounts for any drift between the local and remote timers and allows the systems to stay locked even if not many packets are coming through to trigger the instantaneous phase correction.

  5. Importantly, the frequency hopping and telemetry uplink events are triggered using callbacks from this hwtimer, so critical timings are not missed.

EDIT: Might as well mention, there is a slight complication with the SX1280, as it may assert the busy line and ask us to wait a little before we can send a command.

image

hydra commented 2 years ago

Hi @AlessandroAU

I would very much like to see an ISR approach.

Me too!

With ELRS there is perhaps a 300-500us window where all the logic, processing and SPI transfers must happen. With ELRS, if the critical window is missed then systems might not hop in unison to a new frequency and the link will be lost.

Thanks for posting that, very useful overview of how the system worked. From conversations and reviewing the code from time to time I understood much of that already, your post serves as a great reference for everyone interersted in this or working on the code.

SteveCEvans commented 2 years ago

@AlessandroAU Where does the RX task spend all it's time? Is it waiting for the SPI transfer to complete?

The below are examples of how SPI transfers can be done in a non-blocking manner with quite sophisticated behaviours.

If you take a look at https://github.com/SteveCEvans/betaflight/blob/39b9cac6729a73cedb8bec20452a5ff5dd361038/src/main/drivers/flash_m25p16.c#L329 you'll see that we can setup callbacks for each part of an SPI DMA so you can step though quite a complex sequence of events all under interrupt control. In this example the code repeatedly polls the FLASH device until is it ready, sets a flag once the write enable is issued, and then performs the actual FLASH write.

At https://github.com/SteveCEvans/betaflight/blob/39b9cac6729a73cedb8bec20452a5ff5dd361038/src/main/drivers/accgyro/accgyro_mpu.c#L130 you'll see how an SPI DMA can be triggered in an ISR, and how at https://github.com/SteveCEvans/betaflight/blob/39b9cac6729a73cedb8bec20452a5ff5dd361038/src/main/drivers/accgyro/accgyro_mpu.c#L116 there can be a callback associated with this.

This should enable you to handle quite complex interactions with the rx.

SteveCEvans commented 2 years ago

I've just rebased https://github.com/betaflight/betaflight/pull/10813 against https://github.com/betaflight/betaflight/pull/10573 which I've in turn rebased against master to make it them to merge. You may find that 10813 improves the rx task determinism situation somewhat.

hydra commented 2 years ago

I'm working on a hardware timer with ISR's approach which requires support of STM32 Basic Timers integrated into the firmware timer API.

https://github.com/spracing/betaflight/commits/bf-h7rf-and-config-in-memory-mapped-flash-and-elrs-updates

Basic timer support commit: https://github.com/spracing/betaflight/commit/9f0c7c3b724f996c52125c867b5a6e5be2559ffb

hydra commented 2 years ago

Today I found a bug, with the help of @AlessandroAU we noticed that the SPI communication speed is not correct, the SX1280 can only handle 10Mhz, but the RX SPI code defines the maximum speed to be 13,500,000Mhz.

#define RX_MAX_SPI_CLK_HZ 13500000

However, when measured on the scope it was found the speed was actually 16.4Mhz on the target I was using, so there are two issues: 1) sx1280 driver should somehow set the rxSpiNormalSpeedMhz to 10Mhz and then call rxSpiNormalSpeed in sx1280Init - I have a commit for this already. 2) there's a bug somewhere else as the current maximum of 13.5Mhz shouldn't result in a measured speed of 16.4Mhz.

Here's the fix to 1:

From 92b6ba87508bb0a935c8956f222a1388a22dcd53 Mon Sep 17 00:00:00 2001
From: Dominic Clifton <dominic.clifton@cleanflight.com>
Date: Tue, 24 Aug 2021 14:36:48 +0200
Subject: [PATCH] ExpressLRS - SX1280 can only handle 10Mhz otherwise it locks
 up.

---
 src/main/drivers/rx/rx_spi.c    | 9 ++++++++-
 src/main/drivers/rx/rx_spi.h    | 1 +
 src/main/drivers/rx/rx_sx1280.c | 5 +++++
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/main/drivers/rx/rx_spi.c b/src/main/drivers/rx/rx_spi.c
index e504b90c80..3778fcf2ba 100644
--- a/src/main/drivers/rx/rx_spi.c
+++ b/src/main/drivers/rx/rx_spi.c
@@ -58,6 +58,8 @@ static bool extiLevel = true;
 static volatile bool extiHasOccurred = false;
 static volatile timeUs_t lastExtiTimeUs = 0;

+static uint32_t spiNormalSpeedMhz = RX_MAX_SPI_CLK_HZ;
+
 void rxSpiDevicePreInit(const rxSpiConfig_t *rxSpiConfig)
 {
     spiPreinitRegister(rxSpiConfig->csnTag, IOCFG_IPU, 1);
@@ -75,9 +77,14 @@ void rxSpiExtiHandler(extiCallbackRec_t* callback)
     }
 }

+void rxSpiSetNormalSpeedMhz(uint32_t mhz)
+{
+    spiNormalSpeedMhz = mhz;
+}
+
 void rxSpiNormalSpeed()
 {
-    spiSetClkDivisor(dev, spiCalculateDivider(RX_MAX_SPI_CLK_HZ));
+    spiSetClkDivisor(dev, spiCalculateDivider(spiNormalSpeedMhz));
 }

 void rxSpiStartupSpeed()
diff --git a/src/main/drivers/rx/rx_spi.h b/src/main/drivers/rx/rx_spi.h
index e67af1ec40..8f84ec8d0c 100644
--- a/src/main/drivers/rx/rx_spi.h
+++ b/src/main/drivers/rx/rx_spi.h
@@ -32,6 +32,7 @@ struct rxSpiConfig_s;

 void rxSpiDevicePreInit(const struct rxSpiConfig_s *rxSpiConfig);
 bool rxSpiDeviceInit(const struct rxSpiConfig_s *rxSpiConfig);
+void rxSpiSetNormalSpeedMhz(uint32_t mhz);
 void rxSpiNormalSpeed();
 void rxSpiStartupSpeed();
 void rxSpiDmaEnable(bool enable);
diff --git a/src/main/drivers/rx/rx_sx1280.c b/src/main/drivers/rx/rx_sx1280.c
index 44714a9484..06a8145acf 100644
--- a/src/main/drivers/rx/rx_sx1280.c
+++ b/src/main/drivers/rx/rx_sx1280.c
@@ -39,6 +39,8 @@
 #include "drivers/rx/rx_spi.h"
 #include "drivers/time.h"

+#define SX1280_MAX_SPI_MHZ 10000000
+
 static IO_t busy;

 bool sx1280IsBusy(void)
@@ -66,6 +68,9 @@ bool sx1280Init(IO_t resetPin, IO_t busyPin)
         return false;
     }

+    rxSpiSetNormalSpeedMhz(SX1280_MAX_SPI_MHZ);
+    rxSpiNormalSpeed();
+
     if (resetPin) {
         IOInit(resetPin, OWNER_RX_SPI_EXPRESSLRS_RESET, 0);
         IOConfigGPIO(resetPin, IOCFG_OUT_PP);
--
2.28.0
hydra commented 2 years ago

Ok, happy to report that I've test-flown a timer-based solution on the H7RF today!

@AlessandroAU joined me on a discord and teamviewer chat today and helped me debug a couple of issues with regards to low-LQ link stability. Many thanks!

He also used my HAL approach and ported it to the a StdPeriph driver for the F4.

I'll do some re-basing and make a PR to @phobos- 's branch and paste the link here when I do.

Current code is here:

https://github.com/spracing/betaflight/commits/bf-h7rf-and-config-in-memory-mapped-flash-and-elrs-updates Note:

Flight tested binaries: betaflight_4.3.0_SPRACINGH7RF_e2dcb53ce0.zip

hydra commented 2 years ago

Made good progress in the last 48 hours. More testing was done with low telemetry ratios (e.g. 1:2) and the disarm rx loss appears to be fixed.

https://github.com/spracing/betaflight/commits/bf-h7rf-and-config-in-memory-mapped-flash-and-elrs-updates

Binaries for testing: betaflight_4.3.0_SPRACINGH7RF_e6937f4ea2.zip (Flight tested) betaflight_4.3.0_CRAZYBEEF4SX1280_e6937f4ea2.zip

blockfeed commented 2 years ago

From what I could find, it sounds like AUX11 / AUX12 RSSI channels (in the BF Receiver tab) aren't present in the SPI ELRS implementation. I ask because AUX11 are required to pass LQ to the DJI OSD via the RSSI Value field and I don't see them available (at least on a SPRacing H7RF). Is this the case, and if so are there any plans to add support for this, or is this a hardware limitation? Thanks for your help!

hydra commented 2 years ago

As noted via the SP Racing discord server, No need, the data comes from the RF chip via SPI directly, not via any pseudo channel sent over a UART which is needed for UART based ELRS receivers.

Just make sure to turn RSSI_ADC feature off and then the data for RSSI, dBm and LQ come from the RF chip. Latest SPRacingH7RF test firmware has this feature off by default now.

blockfeed commented 2 years ago

@hydra Thank you for the clarification, that actually helps. I was thinking through the issue and I think you're correct, the LQ is being sent to the OSD properly, as it appears live while configuring the OSD. Unfortunately, DJI Air Unit/Vista only supports RSSI value (enabling LQ display in the limited OSD does nothing). which is why UART based ELRS receivers require that you redirect RSSI Channel to a pseudochannel like you mentioned. It sounds to me like this is a result of the SPI implementation itself missing this feature. Would it be appropriate to list this as a "known limitation"? Hopefully this will be added in a future version. Thank you again.

hydra commented 2 years ago

Just a quick status update on this, some users are reporting testing feedback via the ELRS and SPRacing discord servers. Many successful flights and happy users. I need to find some time to make a PR against the original code and/or create a new PR as @phobos- has been quiet recently.

flosean commented 2 years ago

Hi @hydra , I meet some problem with LQ on CRAZYBEEF4SX1280_e6937f4ea2 build. LQ always display above 100(like 112) on OSD and no matter how far quad was it will never below 100, but the RSSI dbm value display correctly. I use ELRS 1.1 on Happymodel ES24TX and 250hz flash rate. Besides this problem, it works great 09b536581f5d5ad968df1e4822ab79c

JyeSmith commented 2 years ago

@flosean there's a small error in the LQ calc which is fixed but yet to be pushed to the PR.

hydra commented 2 years ago

Hi @hydra , I meet some problem with LQ on CRAZYBEEF4SX1280_e6937f4ea2 build. LQ always display above 100(like 112) on OSD and no matter how far quad was it will never below 100, but the RSSI dbm value display correctly. I use ELRS 1.1 on Happymodel ES24TX and 250hz flash rate. Besides this problem, it works great

It's fixed in here now:

https://github.com/spracing/betaflight/commits/bf-h7rf-and-config-in-memory-mapped-flash-and-elrs-updates

New binaries for the H7RF here: https://github.com/spracing/betaflight/releases/tag/spracingh7-20210916-1539

Rhylthus commented 2 years ago

Hi @hydra , I meet some problem with LQ on CRAZYBEEF4SX1280_e6937f4ea2 build. LQ always display above 100(like 112) on OSD and no matter how far quad was it will never below 100, but the RSSI dbm value display correctly. I use ELRS 1.1 on Happymodel ES24TX and 250hz flash rate. Besides this problem, it works great

It's fixed in here now:

https://github.com/spracing/betaflight/commits/bf-h7rf-and-config-in-memory-mapped-flash-and-elrs-updates

New binaries for the H7RF here: https://github.com/spracing/betaflight/releases/tag/spracingh7-20210916-1539

Hi thanks for the work. Sorry for the noob question but is it possible to have a binaries for CRAZYBEEF4SX1280 ? You previous build works very well on this board. Hope we will have more improvement coming (vbat telemetry will be mega cool)

Thanks.

hydra commented 2 years ago

Today I rebased and squashed a bunch of commits for my new ELRS hardware timer based Phase Locked Loop implementation and made a new PR to @phobos- 's branch.

https://github.com/phobos-/betaflight/pull/3

See also: https://github.com/phobos-/betaflight/pull/3#issuecomment-927745708

@phobos- Please update this PR as outlined in my PR to your repo.

hydra commented 2 years ago

@phobos- I don't have time to investigate build failures today, any chance you could take a look?

hydra commented 2 years ago

Hi thanks for the work. Sorry for the noob question but is it possible to have a binaries for CRAZYBEEF4SX1280 ? You previous build works very well on this board. Hope we will have more improvement coming (vbat telemetry will be mega cool)

Best to ask the manufacturer of the board or @phobos- if he has time to build one for you. Why can you not build it yourself? it's not so hard and a good skill to learn.

Rhylthus commented 2 years ago

Hi thanks for the work. Sorry for the noob question but is it possible to have a binaries for CRAZYBEEF4SX1280 ? You previous build works very well on this board. Hope we will have more improvement coming (vbat telemetry will be mega cool)

Best to ask the manufacturer of the board or @phobos- if he has time to build one for you. Why can you not build it yourself? it's not so hard and a good skill to learn.

Ok thanks for the answer.

phobos- commented 2 years ago

@Rhylthus be patient, I am testing current code with Expresslrs 1.1.0. Once everything is in order I'll update the first post with a new hex.

Rhylthus commented 2 years ago

@Rhylthus be patient, I am testing current code with Expresslrs 1.1.0. Once everything is in order I'll update the first post with a new hex.

Perfect thanks !!!

phobos- commented 2 years ago

@Rhylthus firmware updated in the first post. @blockfeed I added LQ/RSSI on last two channels. RSSI has more smoothing compared to ELRS to make it more usable. Please share your feedback once tested.

blockfeed commented 2 years ago

@phobos- I was able to merge the LQ commit into @hydra 's H7RF betaflight tag 4.3.0-20210927-1107 and it compiled with no issues. I am now able to see LQ in the Air Unit/Vista OSD properly using AUX11 with the built-in SPI-based receiver. Unfortunately it may be a day or two until the weather permits a flight test, but this is promising. Thank you so much for your work on this! I'll give an update as soon as I can.

blockfeed commented 2 years ago

@phobos- @hydra Flight testing was successful and I flew 12 packs with no issues whatsoever. LQ is updated as expected and the values reported are what I'd expect to see (compared to a HM EP1 receiver). This is really exciting. Thank you again for your work on this. The fork I'm building from is here.