Tip: Serial ports in microcontrollers

- Use software serials ONLY for debugging. Software serials are not reliable.
– Use hardware serials primarily for interfacing with devices (GPS etc.)
– Prepare for debugging port in your design
– Program the uC through native programming method (ISP, ICSP) if you don’t have several hardware USARTs
– Make all sorts of cross-compatible adapters and cables for easy debugging
– Use two laptops for development: one for plainly debugging

When picking uC, make sure you have plenty of hardware serials. Usually one isn’t enough.

Simple Arduino Timing class


class jeTime
{
public:
jeTime()
{
reset();
}
float elapsedInSeconds()
{
return (millis()-theTime)/1000.0;
}
int elapsedInMilliSeconds()
{
return millis()-theTime;
}

void reset()
{
theTime = millis();
}
private:
long theTime;
};

Most important NMEA sentence is GPGGA

GGA – essential fix data which provide 3D location and accuracy data.

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

Where:
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
ellipsoid
(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.

How to: quadcopter reversed rotation of your props at betaflight (not 3D)

http://www.rcgroups.com/forums/showpost.php?p=34763753&postcount=28152

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)

Discharge-test: Graphene 65C vs Nano-tech 65C

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.

FC & ESC update speeds

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_sync_denom
  • pid_process_denom

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:

  • gyro is read every 250 us (125*gyro_sync_denom) -> on every loop, at 4kHz
  • PID is ran and motor update every 500us (gyro read interval in uS * pid_process_denom) -> at 2kHz (oneshot125 can handle this easily!)

“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)”

See: http://www.rcgroups.com/forums/showpost.php?p=34196204&postcount=21460

“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. “

http://www.rcgroups.com/forums/showpost.php?p=34196337&postcount=21463

Experimental WAV files

Here’s some experimental WAV files that I have generated.

All files are 44100Hz, stereo.

Package contains:
– 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)

experimental wav files

Technology snippets