any improvement for betafpv lite v2 video?
Hi, im using bwhoop board, using default setting with multi Jp4in1. When i arm, quad goes bumpy… And when i give a little throttle, quad goes fly high to the moon… Already try change min motor command to 3% but still no luck. Any idea? Thanks
I think you need to look at lowering idle my friend.
Not sure about min motor command I don’t think I’ve messed with that command. But lowering idle was super helpful in stopping the bouncy idle.
Your transmitter isn’t giving an idle command.
Altering the idle isn’t the best fix for what is more likely to be vibrations/noise to the gyro signal. Consider looking at the your filter settings by increasing them, lowering PIDs, checking your props and checking the frame for any cracks. The stock PIDs with the beta filters are very high, so if anything is out of wack then you’ll get problems. The beta filtering doesn’t include the Motor_filter which was evident in previous versions of NFE which did a lot to help clean up the signal before the gyro, meaning the gyro could cope with the high PIDs better when there was noise. Thus you may need to change the gyro passes to 80hz of 70hz and lower the Dterm filters in the same manner. Or re-enable the Motor_filter as a test
OK - after 3 months I finally received betafpv lite v2 board! Yes - virus delayed things a lot …
Now, It took me few days until I finally tweaked firmware to my needs and fixed several problems original firmware had. Here are details (if somebody want, I can update github - so far, this fixes are only on my hard disk. I also can post only changes here if somebody want to change only parts of code on their hard disks. Say your wishes - no problem. ):
I noted that betafpv in part of a code (especially in osd.c) used hardcoded index values for AUX channels so any change of default channel assignments in config.h causes various issues. For example, I don’t want to use horizon nor race mode so I used channel 7 for something else like LEDs on/off - so I set RACEMODE to CHAN_OFF and set LEDs to CHAN_7 - and when I turn LEDs on with TX, board shows “racemode” on OSD! Reason is because OSD code in osd.c did not use RACEMODE constant for indexing AUX value but instead that, they hardcoded CHAN_7 as AUX index value in osd.c. Anyway, I replaced all wrong indexes with proper definitions wherever I found this, so now any channel can be used for anything (even channel 9 for arming - which I am using instead channel 5 - don’t ask me why… :))
If you set rates in config.h, OSD would ignore that and show rates from osd.c instead! Yes - for some reason, betafpv put another set of initial rates in osd.c (!?) and used that in OSD instead those from config.h. I also fixed that and now initial rates in OSD are used from config.h and not from separate settings defined in osd.c
If you use arming together with “sticky throttle” like I do in my Devo (“sticky throttle” prevents throttle to be activated if quad is armed with throttle above zero - so if you arm and your throttle is above zero, quad still won’t fly until you pull throttle down to zero first) you could not use OSD because entering OSD requires disarmed state with throttle above zero (center-left) and sticky throttle does not send any throttle value. I changed that in firmware and OSD now can be activated while disarmed but throttle don’t need to be in the middle any more (only throttle-left is enough together with right stick up, as usual) - so now you can enter OSD even if you use Devo sticky throttle mode because no need to have throttle in the middle any more.
So, finally I set my changes, my filters, my rates, my PIDs etc., I put C01 camera on it (acceptable image but has some interference - I am not satisfied very much with it ) and make my first few flights. I must say, it flies pretty good. I think it is due to newer NFE code which is a bit better than some old version I usually use on my other silverware boards (B03, betafpv lite v1.1, beecore lite). But I also noticed few problems. Here they are:
Reception strength is not as on v1.1 and other boards. I noticed lack of controllability in situations where other boards with older NFE works fine. lately, I used Tokyo_Dom’s version of v2 firmware (he bring back bayang telemetry) so I see that packet rate is around 160-170 and fluctuates a lot when quad is next to my TX. On v1.1/beecore boards it is closer to 180-190 and it is stable, and goes max to 200 (B03 boards). When I put v2 board on problematic spot (behind my shed - behind 2 concrete walls), it goes even below 50 while othere boards does not drop much below 80. And I think this is not software issue because you can feel lack of control (throttle works “with a delay” when packet rate goes too low etc.) Antennas on all my whoops are outside canopy so that should not be a point + I tested it on the ground with antennas positioned toward TX while staying behind walls. Not very problematic but just need to note. I’ll check more when I have time.
I had about 10 flights so far - and before one flight, I need to plug/unplug battery for 3 times before quad entered in bind state. For some reason, it did not boot (VTX LED was on but nothing else worked). That is strange. But also not problematic for now - unless something like that happens in flight…
battery values received from board are non-calibrated so stock voltage value in #define REPORTED_TELEMETRY_VOLTAGE is not good for me and causes difference of about 0.12V between what Devo shows and what real voltage on multimeter shows when battery is plugged (that is with LEDs off - with LEDs on, difference is even bigger - but I have LEDs on switch and always keeps them off except when searching for quad ). With stock values, v1, B03 and other boards have very small difference of 0.05V or less so no need to change stock values. But here I needed to calibrate and set propper values or I had tons of false alarms on throttle punches. I assume that bigger difference is due to larger power consumption because of OSD chip…
sometimes when quad is disarmed, OSD flickers heavily. But after arming, it stabilize. Interesting but more annoying than problematic.
So far so good with some minor problems with reception, booting and OSD.
Now, anybody know where to find cables for camera and ST-LINK plug? I think once was posted how that connector is called and where to find it but can’t find that post… Need to get few so I can use different camera and flash board with ST-LINK to use debug mode from Keil (I assume Keil can’t work and debug in DFU)…
And a request for betafpv - make v2.1 where will be possible to turn OSD off on a switch. Now it is impossible without flashing OSD chip which I think it is pretty tricky for most users… (need special tool and pads are hard to use…)
NFE silverware has this sticky throttle enabled by default i believe? If i arm with the throttle above zero, it will flash the LEDs quickly until i bring throttle down to zero, at which point the quad will arm.
Also, my source enabled Telemetry, however BetaFPV’s latest source also enables telemetry plus all the DFU changes. I need to update my source with their changes, and I think your changes would be nice to add in there.
Hm. I did not know that… But I am using sticky throttle in my TX since stock Silverware which did not have that feature. I am sure that old stock NFE version I am using also don’t have it - as I said, I am using very old release which I heavily modded for displaying PIDs on Devo etc. so I never updated it from github any more because lot of changes I made and never had enough time nor patience to “mix” them wihth latest releases (and I am still satisfied how that release flies so I stick to it )
I don’t know if v2 has sticky throttle, but my TX model has it and because I plan to use one model for all quads, I simply changed firmware to support OSD switching with throttle-left move - anyway, it is just one line so I was going that way Now, is this gesture now compatible with betaflight or not, I have no clue - never used betaflight and I never will as long as Silverware exists
Hm, hm, hm… 4 flights today and again 2 booting problems… (it’s about betafpv lite v2 board and firmware with auto DFU detection - for those who did not read my latest posts).
First and third flights were OK. But second and fourth flight - no boot again. For second one I need to plug/unplug 5-6 times before start to bind. When problem occurs, you only have blinking purple (VTX?) LED and static red LED (like it is in DFU mode - but it is not…). After flying, I disconnected battery and tried to connect again just to check will problem occurs again, and yes - it again did not want to bind (same problem). I left it to rest for few minutes (cooling motors etc.), and 3rd flight was fine (binding immediately after plugging lipo). But on fourth - problem again - this time it took 2 plugging/unplugging…
Something strange is happening. I thought maybe it is due to voltage check or something but this happens on fully charged lipos and on partially discharged - no difference. Could be maybe some DFU code that for some reason maybe put board in DFU mode somehow wrongly “thinking” it is connected to USB? Have no clue… But it starts to get annoying…
UPDATE: I forget to mention - all this happens before I turn TX on - so, first I power up quad, and then TX - but problem exists even if TX is ON (on re-bind).
Hmm, sounds like we should have the option to turn off that auto-dfu mode, in the OSD menu. Since we cannot change the menus, we could repurpose one of the other settings, like ToyTX, or LED (i prefer to set this via a channel).
Oh i just remembered that i have had times where i thought it had crashed, showed 0.0v in the OSD, but after 10-20 seconds it booted up correctly (dont remember how long, but it was longer than normal)
Good idea! I’ll try to add that (on channel or LEDs) and see what will happen.
BTW, that 0.0v in OSD is exactly what happens when it does not boot (no data from firmware so no voltage). Did you have that problem on stock v2 firmware or only on DFU version?
UPDATE - I just put a code that will enable/disable auto DFU boot detection based on LED values in OSD (RGB F=DFU off, O=DFU on - can’t be assigned to channels because DFU boot goes before binding) and it is time to check will it work OK now. I’ll post my results here…
Yes I wouldn’t want to assign DFU mode to a channel.
Btw, the stock code overrides the LED channel with the OSD menu value (in Bayang protocol telemetry autobind.c), so be sure to remove that code if you repurposed that setting for DFU.
Also, the bit in main.c for DFU mode is not the only DFU code I believe. Better check the github history to see what else changed with that DFU feature
No problem - I found all code needed to be changed and now settings for LEDs in OSD works for DFU isntead for LEDs (I used new definition to activate that mode where RGB won’t be used for LEDs but for DFU, and new variable for that etc. - I can add changes at your fork if it is OK with you) - now it won’t enter DFU boot mode if you plug it at your PC if you set it as I wrote in my post above (if you set RGB OSD setting as written in my previous post you can turn DFU boot on/off as you wish). And I just tested with 3 flights, and no problem… Need to test more, but looks like this might be solution…
In the mean time, I adapted v2 firmware to work with v1.x, Beecore and BWHOOP B03 pro/standard boards (although I tried only on Bwhoop B03 so far, it should work on all three of those)… Did it just for fun and to check will they fly better than with my old NFE I usually use - and they do fly better…
Thats a great idea actually. Would be nice to bring this fork back to the main NFE silverware project (honestly i am not sure if this is the right terminology, or even something that NFE would want), but make the code universal so all you are changing is the hardware selector for the Lite brushed/brushless and if so it enables the OSD/DFU etc
As for adding to my fork, sure! Btw, i looked the other day on how to add you as a contributor but i couldnt work it out. Still new at this github stuff. Do you need to request to be added?
To be entirely honest, I am in a stage of life that doesnt afford me the same time to dedicate to the f0 silverware project anymore. That said, it’s a community project and it belongs to all who use it. I would merge any pull requests submitted through the github platform or reassign the project to someone else who could merge in pull requests in my absence. It really has nothing to do with what I personally want in my opinion- but to clarify what I would want … I would love to see the project continue to grow and be utilized with community involvement. If there are changes you guys would like to make, consider starting a github “issue” where the change can be discussed and then worked in to the project. Hopefully I will have time one day to get back up to speed with you guys… I’m pretty out of the loop as is now … and hopefully my statement here encourages done of you to take the next steps towards involvement in the project and helping it grow and continue to be relevant and useful with our ever changing hobby!
I’ll try to add to your fork at github and we’ll see will it work.
Regarding changes with hardware selector - it was silverxxx intention from start, and NFE kept that too. But betafpv unfortunatelly messed up that too - so activating BWHOOP does not do entire set of changes - I need to add few "if"s etc. because they did not care about pwm pins and some other stuff so they put some parts of configuration settings for v2 board outside “lite_brushed…” definition and that messed up BWHOOP settings… It would take some time to clean all this, but for now, I only changed what was needed to get it work on B03 just to see will all this work on non-v2 boards…
And DFU update - had 3 more flights on v2 board and still no problems with binding. So, I can say that really looks like turning DFU off prevents boot/binding problems.
Hey sorry i didnt get back to you on this. I think i have finally figured out how to commit and work with github VCS. Well, maybe “worked out” is a little overstating it, i am still doing google searches every second step, but at least its not just manually uploading files via the web interface now (the key was to use Github desktop instead of trying to learn Git/Git Extensions).
- I merged the latest changes from BetaFPV’s master into my source - they had a bunch of changes, including some stuff with the bind key which i didnt quite understand but figured i should keep up with that
- This now uses rx_ bayang_protocol_telemetry_autobind.c for the brushed FC instead of that rx_sbus_dsmx_bayang_switch.c. So i made sure that the T8SG changes are in there
- I added the DFU file creation tool that i now use - builds the DFU file when you build the Keil project automatically.
I hope this doesnt mess with your changes, or make it difficult to merge into my fork. If so, lets work out what the best solution is - i’d like to work towards putting this Lite FC code into the main NFE silverware fork; suitably conditioned with #if statements of course, so that we can have one project for all boards.
I am seeing that Betafpv did a similar thing with the Lite Radio OpenTX source - its basically Taranis X7 source, but since they added a few minor changes, they created their own fork which is now NOT supported by OpenTX. Hence they had to release their own OpenTX companion to talk to it. But if you can cope without those small changes (flashing the power LED on low battery), you can safely flash the latest X7 firmware on it and have it working with OpenTX companion
I’ll check and add things to your fork as soon as I find time (I hope this week).
I don’t like to experiment too much with new versions (unless I am sure that changes will improve things or make them suitable for my needs - so first need to detect what they changed before updating ) so, for now and for my purposes, on my V2 (and also on V1.1 boards) I’ll use my modded version of your version which I downloaded before these latest changes you merged.
Does anyone know why USE_MULTI has such different aux channel mapping to USE_DEVO? Which is the more correct mapping? I don’t like how USE_MULTI skips channel 11 but why do we even need that condition in the code?
I am making a multiprotocol module for my Lite radio 2 and since my other radio is a Deviation firmware the aux channels are all over the placr
At least with the lite fc v2 I could change the mapping on the quad and fly it!
is this board could use external SBUS RX?