Skip to main content

Topic: X666 + KK2 moj prvi quad (Read 120798 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Odg: X666 + KK2 moj prvi quad

Reply #315
I vise nego dobro,
bit ce cvrsci, laksi i najbitnije manje vibracija.

Odg: X666 + KK2 moj prvi quad

Reply #316
Izgleda da je SimonK sredio probleme s NTM motorima.
Jos da znam mogu li vratiti na staro ako mi se ne svidja, tj ima li negdje orginal firmware za blue series?

Jumping from low to high _speed_ should no longer lose track of timing
because of excessive averaging. This caused problems in some cases even
without ZC tracking issues, such as with the NTM 28-26 1200KV.



 Originally Posted by simonk View Post
Ok, way too many changes have accumulated without a release, so here is a FETkiller™ testing/alpha release. I have NOT flight tested this yet, but it might be raining by the time I do.

git shortlog --no-merges d8f53c2c2..a77d1c339

Marcin Cieslak (6):
Remove suprious HTML from end of file
Add a simple BSDmakefile for testing
Add .obj files to .gitignore
Assembler can be overriden on the commandline
Replace .ifdefs with #ifdefs
Add explicit dependency on tgy.asm

Simon Kirby (38):
Beep periodically when RC signal is lost (patch from alsav).
Add support for ramp-up, pulsed (regenerative) braking.
Port missing Makefile targets to BSDmakefile.
Comment and typo fixes.
Simplify and optimize rcp_int by using OCR1B instead of tracking 24 bits.
Stop using 4 registers just to avoid 4 extra cycles in PWM interrupt, and implement optional complementary PWM.
Use TIFR.OCF1B instead of OCT1B_PENDING. No OCF1B interrupt required.
Support wider calibration range all the way from 0 to MAX_RC_PULS.
Use shorter RC timeout while armed (HK i86 workaround).
BSDmakefile should work now. Waiting on avra -i option so we can drop the symlink hack.
Build up start power to PWR_MAX_START more quickly.
Sync loss avoidance, comp PWM, ZC DC bias cancellation, adjustable timing advance, and startup and timeout improvements.
Halve ZC filter time when running at 8MHz.
Add tp_8khz target for "type 1" clones that blow up at >8kHz PWM.
Fix typo and prepare for merging with Makefile.
Move BSDmakefile over to Makefile.
Fix math rounding error when subi/sbci is used for adding a constant.
Don't accidentally turn off power for too long, and don't forget to track timing on wait_timeout.
Allow start duty to reach PWR_MAX_START again.
Don't wait for demagnetization during startup.
Match up the sync debug on the MOSI port with stock Mystery firmware.
Move ZC loop shifting to update_timing.
Calculate the needed motor timings when needed instead of in advance.
Move boot loader to boot.inc.
Don't halve ZC loop count on 8MHz MCUs -- the timing will already be half.
Fix powerskip regression since c09b6930b -- don't include carry in decrement.
Reduce the powerskipping timeout to twice the minimum required.
Macros for adiw/sbiw that allow any immediate. Allow <1kHz PWM again.
Calculate ZC check count on demand instead of in advance.
Remove unused TIMING_RUN.
Optimize update_timing and crash set_new_duty on the end.
Keep rc_timeout consistent when driving (no decay from RCP_TOT).
Optimize PWM halving.
Disable interrupts for a shorter period in set_ocr1a_abs.

..I removed some junk from the above, but there are lots of things that might break there, as you can see. Most people are waiting on this commit:

commit 0593fbf79a8205f04c8e52a7633ee84ad4c7a6be
Author: Simon Kirby <sim@netnation.com>
Date: Tue Sep 11 01:49:38 2012 -0700

Sync loss avoidance, comp PWM, ZC DC bias cancellation, adjustable timing
advance, and startup and timeout improvements.

Warning: This is a significant commit. I even broke a few FETs because of
some earlier bugs. Test carefully.

Complementary PWM is now supported, ala wii-esc. This has an interesting
effect of having the motor speed more closely and more quickly track the
duty cycle even without any active braking or closed-loop controlling.
Warning: It may break P/N (or other) boards.

Jumping from low to high _speed_ should no longer lose track of timing
because of excessive averaging. This caused problems in some cases even
without ZC tracking issues, such as with the NTM 28-26 1200KV.

Jumping from low to high duty cycle that results in a demagnetization
period that exceeds the blanking window will now be tracked and if
excessive (approaching 30 degrees), PWM will be stopped 30 -
MOTOR_ADVANCE degrees in order to avoid blinding the ZC in the next
commutation. This should (in theory) be smoother than the wii-esc
approach of jumping forward, as the power will only be cut for about 15
degrees. This should solve problems with the expensive and/or pancake
motors that have higher inductance and lower winding resistance such as
the RCTigerMotor MT-3506. Thank you to ziss_dm for the ideas, discussion,
and awesome LTSpice simulation!

Jumping from run to brake to run again (or run to RC timeout to run)
while the motor is spinning quickly will no longer cause sync loss due
to excessive ZC filter length and/or blanking periods. Instead, we look
briefly without power to see if the motor is spinning and align to it
before inducing any demagnetization current or PWM noise.

Starting NTM 28-30 750KV motors should no longer squeal in some cases.
This was a bug where zc_filter_time was not being set during starting.
The long blanking period is instead taken care of by the ZC filtering.

DC bias is now cancelled from the commutation timing. This might help
at very low speeds, but it's probably not that useful.

Timers are now set to absolute values precalculated by update_timing.
This avoids skew from processing overhead. There is still a little bit of
skew from the ZC filtering, but I don't see any way around this. Also,
boards with larger sense filtering capacitors such as the F-30A line will
have slightly droopy timing as RPM increases, but this should not be a
big deal. MOTOR_ADVANCE has changed from 15 to 18 degrees, which looks
almost perfect on the 'scope for everything I have tried with.

Let me know how it goes! I won't upload it to github downloads until I get some good feedback and I actually do flight test it.


Odg: X666 + KK2 moj prvi quad

Reply #318
Ovo je dobro za snimanje, ako faca otkloni tiltanje s boljim servačima. Za FPV se ne ne koristi gimbail, jer FPV kamera mora biti uparena kruto na os coptera.
Kršite svoje koptere da biste ih bolje upoznali ! :-)
A sada i avione! :-(



Odg: X666 + KK2 moj prvi quad

Reply #321
Malo i po snjegu.

Ne mogu 100% potvrditi ali meni se cini da gopro bolje snima s novim firmwareom ( ili snjeg daje dobro svjetlo).



 

Odg: X666 + KK2 moj prvi quad

Reply #324
ima nas ima koji pratimo  ;)



Odg: X666 + KK2 moj prvi quad

Reply #327
Evo pratim i ja non stop jer slažem isti frame i KK2 pločicu... motori su DT750 a elise 10x4.7, ESC Turnigy plush 25A... nego koji timing koristiš za ESC-ove?

Mislim da sam stavio auto, pretpostavljam da je sam prebacio na high, to sam ostavio na prog. card kako je bilo jer nisam bio siguran sta za NTM.

Odg: X666 + KK2 moj prvi quad

Reply #328
Evo malo rezultata testiranja spuzvice za smanjenje vibracija na kameri

Anti-Vibration foam (Orange Latex) 190mm x 140mm x 6mm
http://www.hobbyking.com/hobbyking/store/uh_viewitem.asp?idproduct=26457&aff=448825

Video s kamere je bez ikakvih obrada, orginal, osim prekodiran za youtube (720p).

http://www.youtube.com/watch?v=Gd7uMZWuQ1U

Boja je svakako interesantna, dosta je mekana pa sam stavio prvo spuzvicu od KK2 pakiranja koju sam i prije stavljao i dodao tu narandjstu oko kamere gdje je kontakt s trakom i ostalim, kamera nigdje direktno nista tvrdo ne dodiruje na svim kontaktima je spuzvica.
Nisam jos probao dodati jos nesto izmedju baterije i okvira da jos smanjim, mozda probam i to.