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:
- 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)”
“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)
print "server said %s and %s" % (content, txt)
delay / sleep
HTTP get / request
resp, content = httplib2.Http().request("http://example.fi")
except urllib2.HTTPError, exc:
except urllib2.URLError, exc:
print "Failed because:", exc.reason
"""this is some test documentation in the function"""
message = textwrap.dedent("""\
""" % (FROM, TO, SUBJECT, TEXT))
# Send the mail
server = smtplib.SMTP(SERVER)
server.sendmail(FROM, TO, message)
Raspberry Pi Zero + SD card 8.8 grams
Raspberry Pi Zero + SD card + pin header 11.8 grams
Raspberry Pi Zero + SD card + USB wlan adapter (Asus USB-N10 without covers) 11.9 grams
Measured power consumption at 3.3V fed directly to header:
150mA without USB devices
350mA with Asus N10 during ping in weak network connection
Write a bash script on Raspberry Pi:
raspistill -o vattu.jpg
curl --form "firstname.lastname@example.org" http://domain.fi/vattu.php
and PHP at server side to process the upload:
$userfile_name = $_FILES['fileupload']['tmp_name'];
if (move_uploaded_file($_FILES['fileupload']['tmp_name'], "vattu.jpg"))