notfastenuf / nfe_quicksilver Goto Github PK

Some reports have come in regarding a possible bug in smart audio. In these reports - the channel value displayed in OSD and possibly in GUI is reverting to A1 while the vtx is still actually transmitting on the last user configured channel. This bug needs confirmation that it can be replicated and it would be helpful to know what hardware it is appearing on.

Some code is already in place in the dshot driver to support motor beeps. It seems reasonable to go ahead and link the dshot motor beeps to the Aux_Buzzer feature. Ideally the logic behind the buzzer could kick out dshot beeps the same way - except for in flight where a real buzzer can beep but dshot is busy flying the quad. I will be working on this one soon and am open to any feedback.

This has been requested a few times .... making the changes to the osd timer is easily done, but some thought and discussion should be put into how and where the "switch" should be placed in both OSD and GUI. Once this is discussed and decided - this feature can be added

I am out of the loop on ELRS but hope to dive in soon. I'm being told that there are fc being built with ELRS receiver connected to mcu via SPI? If anyone has a circuit diagram for an ELRS spi based receiver - please link it here. I would love to build one for the breadboard to make debugging easier and get started on support.

It may be worth considering to add dshot 1200. Quicksilver dshot is performed using only one timer and a single dma stream ( to eliminate troublesome hardware conflicts) - but as such comes at a price of "cascading" through each gpio port to generate the signals. Also due to the F4 dma hardware bug - Dshot has to be blocking with any activity on SPI1. This means that running slower dshot times can cause looptime to fall back to slower values, and hardware where motor pins are split up on multiple gpio ports can also take up more time causing slower looptimes. Some of this loss, (although really not huge issue or even all that common) could be reclaimed by adding support for dshot 1200.

So this issue is open for discussion if anyone is really worried about squeezing the absolute fastest possible looptime out - or is experiencing "looptime warnings" in osd status messages.

Quicksilver is missing this.

Quicksilver uses a variable labeled Bind_Saved to change the behavior of many rx protocols at time of boot. This variable must be toggled by the user from NO to YES and then must be saved with a write command to flash memory.

For Unified Serial protocol - the switch from NO to YES will turn off DSM bind pulses, and will stop autodetect from searching all the protocols for a receiver lock - only using the saved protocol type.
For spi based receivers - this process will save the rx bind data to flash memory so that the receiver is bound. Otherwise it is ready to bind to a TX on boot.

Traditionally, this process could only be done with the UP UP UP stick gesture (status led 1 blink for YES - two blinks for NO) followed by the DOWN DOWN DOWN stick gesture to save to flash memory. It was thought that successfully performing a the stick gesture was sort of a "sanity check" that the sticks were configured properly in both channel order and range of motion. Failure to be able to perform the gesture would mean it is certainly unsafe to try to fly. However, there have been multiple requests to add a toggle button to USB GUI. This issue is a placeholder for discussion and to make sure the request is not forgotten.

One report has rolled in so far regarding an IBUS receiver which was not detected by the universal serial protocol. Once hard set to IBUS in config.h and re-compiled - the receiver seemed to operate normally with one exception. The packet rate based rssi calculation was reported to show 29 when it probably should have been at 100%.

Problem reported on the following gear:
Model: Fli14
Item Name: 2.4G 14CH Compatible Flysky AFHDS-2A Receiver
Channel: 14CH
Protocol: AFHDS-2A

Using Bluejay 0.14 on CrazybeeF4 target It is not possible to access the esc settings on the motors tab. Motor direction check works correctly but when the load button is pressed the esc tones sound then nothing shows up. Everything else in the configurstor still works.
No useful log, only a line indicating motor test activated, nothing about esc.

As the title says .... there are multiple anecdotal accounts of less range with QS. Seems to affect both redpine and frsky protocols equally.

I propose we start discussion with determining a standardized way to evaluate/quantify this. I'm open to suggestion....

Currently, the user has to know the UUU/DDD gesture to save bind once they are bound. This is leading to confusion as there is no indication on the page to have to do that OR button or other UI Action to save bind.

Steps to reproduce the behavior:

Go to Receiver Tab
Bind from radio, notice the Save says "no"
There is no indication or UI Action to change no to yes
Enhancement:

Add text next to the page to say "Use Up, Up, Up, Down, Down, Down on your radio to save"
OR add a Save button or other UI Action on the page that changes from disabled to active when the user is bound but hasn't saved.

Some request have come in to make this VTX screen element diplay channel data in the same format as Betaflight. Currently the frequency only is displayed. This issue is an open forum discussion for those who want to see change in this format to voice their opinions.