BATT2_ and TMODE Parameters Skyviper GPS defaults

Why are these default settings used with the SV-GPS?

BATT2_CAPACITY: Battery capacity

Capacity of the battery in mAh when full

This is set to 3300 mAh when the SV uses a 1200 mAh battery . Why are we using false data as the default setting ? What will changing this to the true value effect ?

TMODE_MODE1: Tmode first mode

This is the initial mode when the vehicle is first turned on. This mode is assumed to not require GPS

Here SV GPS has Loiter set as first mode which requires GPS , Why?

TMODE_MODE2: Tmode second mode

This is the secondary mode. This mode is assumed to require GPS

With SV this is set to AltHold which is a mode that does not require GPS .
It just seems like these two settings are reversed according to the description used by ARDUCOPTER.

I’m confused :warning::no_entry::interrobang::exploding_head::thinking:

A few things.

First, toy_mode.cpp has specific provisions in it to allow it to automatically switch to Loiter mode once GPS is good. However, becauswe it is a toy, they (probably) didn’t want to force the user to wait for GPS. So it will start-up in Loiter mode, but the GPS light flashes. Once you get GPS, it’ll set the home positon (at that spot) and switch to Loiter. I think I understand why they did this (to make it simple for users) but i’ve had to answer dozens of “complaints” about fly-aways in Loiter, when it reality, they weren’t really in Loiter mode. Anyways, in general you don’t want your “first mode” to be a GPS required mode, but toy_mode compensates. Probably the comment within APWeb just needs to be changed. Likely, SV could have saved a few fly-aways by preventing the user from taking off in Loiter mode selection when GPS wasn’t ready.

The BATT1/2_Capacity parameters aren’t used. There is another parameter BATT_MONITOR that determines what readings it uses for the battery monitoring. It is set to Voltage only. So the SV only watches the pins for voltage levels. The Capacity is just set to a default value within Ardupilot code.

1 Like

Thanks LordNeeko , I remember reading a post about not it measuring current or some thing . So it gives battery voltage only . What should min voltage be ?

Test yours. Hover just above the ground until it drops out of the sky. Then use the logs to find out what that voltage is. Then add like 0.10-0.20 v for the crit voltage. Either way use the log to find out how much time you might need to get it home after critical alarm.

I’ve read where adding a 1000uf capacitor on the battery input can help. I only had a 330uf to work with and it dropped slower when full throttle was applied with a voltage meter attached but didn’t change the level the app detected the voltage level to be at. Still too low too quick.

Also, keep in mind that there are Battery Low Paramaters and Battery Critical Paramaters.

By default, I don’t think the SV does anything with the Battery Low alarm. (I can’t remember the default as I changed the behavior)

But the interesting parameter is
With this parameter you can prevent the alarm from triggering during periods of high motor output. If you watch the battery level on the App, you’ll see the battery level drop dramatically when you throttle up. However,with this timer, it’ll prevent the alarm from triggering until it has been below the alarm value for more than X seconds. I set this up to be my critical alarm instead of my low alarm, by setting the crit value just above the absolute cut off value and low alarm to the value I tested for when I HAD to come home. Then, I also set my BATT_Low action to “NONE” because I got tired of RTL flying me into trees when it triggered. But the SV transmitter and SV toy_mode.cpp sets the lights to flash and Tx to beep. So that’s my “alarm” instead of auto RTL.

Hopefully all that made sense. Basically, I use the “Low” alarm and not the Crit alarm for the specific reason that I wanted to take advantage of the BATT_Low_Timer parameter tokeep it from triggering the battery failsafe when using high throttle.