EvvGC 3/2axis Brushless Gimbal Controller (Open Source) - Page 53 - RC Groups
Jul 09, 2013, 11:48 AM
Registered User
Quote:
 Originally Posted by bektorkhan Nope, there are protection diodes on every pin in all IC's connected to VDD and GND. These diodes can also be used to measure chip temp! So if you pullup with a moderate current, the voltage on the pin will be +3.3V + 0.6V = +3.9V. A pulldown below GND would result in - 0.6V on the pin. And that's within spec!
The data sheet has this in 5.2 Absolute maximum ratings, Table 8
Injected current on five volt tolerant pins(3)

3. Positive injection is not possible on these I/Os. A negative injection is induced by VIN<VSS. IINJ(PIN) must
never be exceeded. Refer to Table 7: Voltage characteristics for the maximum allowed input voltage values. -5/+0mA
A positive injection is induced by VIN>VDD while a negative injection is induced by VIN<VSS.
IINJ(PIN) must never be exceeded. Refer to Table 7: Voltage characteristics for the maximum allowed input voltage values.

ΣIINJ(PIN) Total injected current (sum of all I/O and control pins)(5) ± 25mA
5. When several inputs are submitted to a current injection, the maximum ΣIINJ(PIN) is the absolute sum of the
positive and negative injected currents (instantaneous values).

0mA is not that much. Feel free to pull up the pins to 12V on your board.
Jul 09, 2013, 11:50 AM
Registered User
Quote:
 Originally Posted by bektorkhan Nope, there are protection diodes on every pin in all IC's connected to VDD and GND. These diodes can also be used to measure chip temp! So if you pullup with a moderate current, the voltage on the pin will be +3.3V + 0.6V = +3.9V. A pulldown below GND would result in - 0.6V on the pin. And that's within spec! If one want you could put a diode from the pin to VDD to releave the protectiondiode. But it would not be necessary. I am trying to find a fix for people that have the 1.2/1.3pre board, because 3.3V is not enough to realiably saturate the lowside N-Fet. And it looks like there's alot of these boards out!!! /Mikael
Hi,

Doing this will most likely result in a lot more blown boards! By changing to a pullup instead of pulldown the software will need changing to invert the drive signal for the NMOS fet. Therefore if anyone accidentally used an earlier version of the code, they would get shoot through and blow up the FET.

Two versions of code would then be needed one for the old design and one for the new causing more confusion.

Also the mosfet is fully turned on with 3.3V applied to the gate. Please see the transfer characteristics graph. The RDS value is very high for the device during this so really not ideal for operation, but if they have not been any major overheating problems with the boards in use currently then we should just leave it and move on.

People with v1.3 and below should see this as a development platform for software and wait for V2 for a proper protected board.

An easy solution would be to change the mosfet for one with a lower VGS on threshold. But i am not going to spend time to look into this.
Jul 09, 2013, 12:35 PM
Registered User
Quote:
 Originally Posted by bektorkhan Nope, there are protection diodes on every pin in all IC's connected to VDD and GND. These diodes can also be used to measure chip temp! So if you pullup with a moderate current, the voltage on the pin will be +3.3V + 0.6V = +3.9V. A pulldown below GND would result in - 0.6V on the pin. And that's within spec! If one want you could put a diode from the pin to VDD to releave the protectiondiode. But it would not be necessary. I am trying to find a fix for people that have the 1.2/1.3pre board, because 3.3V is not enough to realiably saturate the lowside N-Fet. And it looks like there's alot of these boards out!!! /Mikael
Do you have tested v1.2 and have any problems with overheating or something like that?

I have tested a lot and none of those fets blows up or overheats because of too low G-S voltage.

Also look at the page 4, "transfer characteristics"
http://www.vishay.com/docs/68971/si4599dy.pdf
Jul 09, 2013, 01:03 PM
Registered User
Quote:
 Originally Posted by Jef79m ok.. so i got mine going ok, but it obviously needs tuning.. http://youtu.be/zBvyL8H_fUA and, is it meant to make that noise?
I think that's the first time I've heard audio on a video test ... Sounds like the motors are being driven constantly.

I know this works more like a stepper motor controller than an ESC does to drive a motor to spin constantly. I suspect that's the 8khz frequency of the PWM. 16khz would probably make those less noticeable (but the software doesn't support that yet). I wonder if that is why alexmos and martinez are both going to 16khz, I heard the noise was pretty noticable at the 8khz speed.

Curious were either the motors, or the controller (FETS) hot or warm to the touch after such a short test?

Glad you got it working however. And it actually looked pretty good...

Lastly does it make that noise from initial power up to power down, it's not dependent on movement?

Just trying to educate myself.

Thanks for Sharing!
Alan
Jul 09, 2013, 01:11 PM
Registered User
Quote:
 Originally Posted by evvaldis Do you have tested v1.2 and have any problems with overheating or something like that? I have tested a lot and none of those fets blows up or overheats because of too low G-S voltage. Also look at the page 4, "transfer characteristics" http://www.vishay.com/docs/68971/si4599dy.pdf
I'm feeling like a broken record here... And it's clear that software is the long pole in the tent right now.

Are we any closer to a public release with change control mechanism such that people can start making and publishing changes...

And on a non-limited development platform (free keil with 32k limit isn't going to cut it).. Eclipse preferred, me personally - I don't care if it's makefile or c project based. But IHMO, it should be based on the latest gnu gcc for arm from here...https://launchpad.net/gcc-arm-embedded Which is not limited and becoming for the open source development standard for arm based devices.

Just wanting to know... We've kicked hardware in the butt now and it's taken off nicely - THANKS to all the contributions there. Now we *really* need to do the same with software.

One last editorial comment from the peanut gallery.... Open source is a funny thing. It brings out the opinion in everyone. No-one should take it personally, there are different cultures represented here, different work ethics, etc. Back and forth is good as long as it's constructive. ...

But enough about that... I'm off to finish up a couple of other things so I can get the pre1.3ce2 out for you all.

Thanks
Alan - the peanut gallery
 Jul 09, 2013, 01:32 PM Registered User Hi Human hearing is 20Hz to 20KHz so it would be possible to here 8Khz pwm. Also you might hear 16KHz, but that all depends on how old you are! Regarding the software and Eclipse my dream would be to get this working under the coide eclipse package as it comes ready to go for programming and using the debug tools with STM32 with no real setup required. (Im also already using it for other projects so its mainly me being lazy) Also ideally we would move away from Altium for hardware design and use something like Designspark as Altium is not exactally open source friendly! Dan
 Jul 09, 2013, 02:02 PM Registered User @Alan- broken record indeed, but you are playing the right tune. I think CE should proceed with the following steps- -Migrate project file hosting to somewhere so more people can work on it and publish changes. Will github suffice? -Migrate the development platform to something open-source without code limits. Eclipse w/ latest gnu gcc for arm -Change PWM to a higher frequency- 16mhz at a minimum for quiet operation @Pilt- what is "coide eclipse package"? Is it like this tutorial? https://sites.google.com/site/stm32d...ry-development -Tom
Jul 09, 2013, 02:04 PM
Registered User
Quote:
 Originally Posted by Pilt Also ideally we would move away from Altium for hardware design and use something like Designspark as Altium is not exactally open source friendly!
I vote for Eagle, as it's free (this board fits within limitations for Free edition)
Jul 09, 2013, 02:07 PM
Registered User
Quote:
 Originally Posted by Tom Frisch @Alan- broken record indeed, but you are playing the right tune. I think CE should proceed with the following steps- -Migrate project file hosting to somewhere so more people can work on it and publish changes. Will github suffice? -Migrate the development platform to something open-source without code limits. Eclipse w/ latest gnu gcc for arm -Change PWM to a higher frequency- 16mhz at a minimum for quiet operation @Pilt- what is "coide eclipse package"? Is it like this tutorial? https://sites.google.com/site/stm32d...ry-development -Tom
Tom, no don't got down the code sourcery route... google coide arm and you'll find its an entire eclipse based ide, etc...

I'll help ya ... http://www.coocox.org/CooCox_CoIDE.htm note comments about still needing to get the gnu gcc toolchain, reference my post above.

Something, anything is better than being limited to 32k... I'm surprised that the code will even fit... granted it's about 20+k without all the console overhead (which Keil seems to give you for free), add that it grows to 50+k (btw, I suggest we get ride of all the printf overhead, that's just way too much code for nothing...and I think there are just as good, less overhead options for output (altho granted printf is easy).

Alan
Jul 09, 2013, 02:11 PM
Registered User
Quote:
 Originally Posted by acc007 I vote for Eagle, as it's free (this board fits within limitations for Free edition)
For v2.0 maybe, but I'm certainly *NOT* going to move the 1.x to eagle...

BTW most will tell you that Altium is much easier to work in and I have to admit once I remembered what I'd forgotten, I like it better than eagle...

Oh and yes, GIT would be preferred and doing so on GitHub is rather easy.
 Jul 09, 2013, 02:46 PM Registered User I don't know Altium - however it's not free. You even need to register to download the viewer. I didn't want to share my email with them, therefore I couldn't have viewed the 1.3ce1 design github +1 from me as well
 Jul 09, 2013, 02:53 PM Registered User Github is the way to go in my opinion. I use it for all sorts of project, open and closed source. Adam, FYI I am still not able to get your code to build, but have not had a chance to dig too deep.
 Jul 09, 2013, 03:15 PM Registered User First time messing with Github, so not sure if I did this right, but I set up a repository and uploaded the current v1.2 hardware, firmware v0.2, and GUI v0.1. https://github.com/Tom11Films/EvvGC-ce
 Jul 09, 2013, 04:17 PM Registered User Designspark is what i use for most schematic and layout, and has modelsource, so most componants can be brought straight in from the internet (If RS stocks them!). But it is nowhere as complete as Altium, but its not that bad. Regarding changing to 16Khz, someone should experiment with 8Khz and then 16Khz, and compare the FET temperatures as it will increase switching losses and cause the fets to heat up slightly more. Why not try 24Khz while you are there so you cant hear it! Due to the design of directly driving the FETS from the STM32 there may be issues with turning the devices on and off completely at higher frequencies, although this wont be a problem in v2! Dan
Jul 09, 2013, 05:49 PM
Registered User
Quote:
 Originally Posted by aadamson evvaldis, Can we get an update on the software, and it's moving to Git, Eclipse, etc? Seems that's going to be the area of focus as soon as we get to this 1.3x version... Thanks, Alan
Code is moving to eclipse+Code Sourcery, but slower than I thought, because it is not my day job..
Also, I have lots of others things to do at this time, one of them is to answer tons of emails about v1.2... people thinks that v1.2 is rubbish because of all that talks about 1.3xxxx, even this is not true! weakest link on modified v1.2 is software, and I am trying to push it forward now..

I saw there was code already ported to eclipse and github, we(you) can continue to work on this code if you like.

I would like to work more on hardware than software.

p.s.thinking maybe cocox would be better to involve more people.. For example for me it is interesting to play with code, add new features, but since I am not programmer I hate that makefile sh**..
This is the reason why arduino is so popular and has lots of interesting projects, is easy to learn, and you don't have to be old geek to create something new.
Last edited by evvaldis; Jul 09, 2013 at 06:03 PM.