theTime = millis();
theTime = millis();
GGA – essential fix data which provide 3D location and accuracy data.
GGA Global Positioning System Fix Data
123519 Fix taken at 12:35:19 UTC
4807.038,N Latitude 48 deg 07.038′ N
01131.000,E Longitude 11 deg 31.000′ E
1 Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode
08 Number of satellites being tracked
0.9 Horizontal dilution of position
545.4,M Altitude, Meters, above mean sea level
46.9,M Height of geoid (mean sea level) above WGS84
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
*47 the checksum data, always begins with *
If the height of geoid is missing then the altitude should be suspect. Some non-standard implementations report altitude with respect to the ellipsoid rather than geoid altitude. Some units do not report negative altitudes at all. This is the only sentence that reports altitude.
REMEMBER: if you screw some of these settings, the copter will violently start to oscillate. If you do first test with props on at hand, grip the copter VERY well.
enter following cli command:
set yaw_motor_direction = -1
also you might need to apply this command:
rxrange 2 2000 1000
.. depending if your yaw direction is wrong. When I had stick arming, I had to enter this to get stick arming to left corner and still get yaw to work in correct directions.
(and ofcourse, reverse your motor rotation direction at ESC and “mirror” your prop rotation direction)
You need to install package gcc-arm-none-eabi for example http://packages.ubuntu.com/trusty/devel/gcc-arm-none-eabi. That’s all!
All batteries fully loaded before tests. The test is constant resistance (1ohm) (causing about 200W discharge power) which is about 14-15A.
All kept their cell voltages really even during the tests. The 25C (really used and old battery) buffed a little at the end but took it’s shape after resting.
All batteries were a little bit warm, but certainly not hot. Ambient temperature was about 20deg celcius.
|Multishot shortest pulse||5 microseconds|
|Multishot longest pulse||25 microseconds (40kHz)Designed to allow 32kHz update frequency, so 40-32 = 7kHz “sleep” time between pulses.|
|Oneshot42 shortest pulse||42 microseconds|
|Oneshot42 longest pulse||83 (?) microseconds (=250/3?)|
|Oneshot125 shortest pulse||125 microseconds|
|Oneshot125 longest pulse||4kHz||250 microseconds|
|Betaflight 2.5 looptime on SPI targets||8kHz||125 microseconds|
|Betaflight 2.5 looptime on F1 boards||4kHz||250 microseconds|
On betaflight the frequencies are defined by two denom-values:
gyro read interval in uS = 125 * gyro_sync_denom
motor update interval in uS = gyro read interval in uS * pid_process_denom
For example Naze32 is set to looptime 250us. The betaflight sets both denom-values to 2, therefore:
“even at 8 kHz sampling time which is only possible on boards running spi connectivity to the gyro, your PID loops and thus motor update will only be running 4khz (actually just short) (in fact may even be 2666hz, don’t recall, as Boris has pointed out, it doesn’t seem to make much difference)
Oneshot125 handles this fine.
There is no driver for using oneshot42 or multishot (other than star wars startup tones)”
“From higher sampling the filter delays are being removed. You get less delay and cleaner signal in your pid loop.
You essentially dont need something faster than oneshot125 if you dont care about running @4khz motor update speeds. “
Here’s some experimental WAV files that I have generated.
All files are 44100Hz, stereo.
– 2 points (aka samples) 44100Hz stereo.wav (meaning the signal goes from low to high)
– 4 points (aka samples) 44100Hz stereo.wav (low, high, low, high)
– 440hz square 1 cycle.wav (tiniest 440hz square wave WAV file that you can generate)
– 440hz square 10 cycles.wav (similar to previous but repeats 10 times)
– 44100Hz stereo no data.wav (do data at all, no samples, basically only the WAV header)