Lion Software

[Gandolf]

The EEPROM writing works fine with optimization -0s but it does not work with optimization -01.

So the optimization in the WINAVR or GCC compiler is the problem.

Gandolf

[Gandolf]

Hi,

Everything is working now!  Even the EEPROM stuff.  I just went back to optimization -Os and fixed the few issues there and all is good.  I read into how the GCC optimizations work but it was way beyond me...  But I take back everything thing I said about optimization -Os.  Apparently the only things worse than it are any of the other optimizations! 

Here is the latest code with everything working and even pre-cocking now!   

http://extreme-fire.com/Lion/20091107/

I made a pre-cocking movie too to show how it works:

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

Gandolf

[skag187]

 that made my day

great video

[hunterseeker5]

that made my day too....

[Gandolf]

Hi,

I'll post this under "software" since that is now where this whole game is at!!

Here are the current codes:

http://extreme-fire.com/Lion/20091114/SW-Lion-1010.c

http://extreme-fire.com/Lion/20091114/Lion.h
http://extreme-fire.com/Lion/20091114/lioneeprom.h
http://extreme-fire.com/Lion/20091114/LionLCD.h

The new  lioneeprom.h  is like the 'librarian' for the EEPROM storage.  It knows where to stick it and where to find it.  Since I have the EEPROM working now, I have not used the LCD display much...  Easier just to pull the whole data file out to check things.

ATMEL's Studio 4 likes to store the HEX file in this format:

http://extreme-fire.com/Lion/20091114/out1.hex

Sort of a PITA realy...  It does not import into a spreadsheet well as far as I can find.  A GCC program could convert it very nicely though into a very comprehensive text file...

I played with microphone pickups some.  Peizo sensors seem way too biased into the high frequencies:



Lot of noise there.  But it was set right against the mechbox.  

The Wideband accelerometer gave this:



That slow negative valley (~5mS) is the piston traveling forward at 7.9mV/G...  The top spike (~16mS) is when it hits the end.  So that is -126G and +380G!!  You would "think" that would be easy to detect              

The far later spike (t + 40mS) is very prevalent and I think it is the spring bouncing around or something....

But really, "just the software" seems to rule far better....  I don't think external sensors are going to be very needed unless you are doing something really special...

This is cool!

My worst case test system:



Now that's an 'airsoft gun' a "REAL scientist" can relate too!!!      LOTs of wires, measurements, and data!!!    

Let me tell ya though...  Tamiya connectors SUCK big time!!!  Get ride of them on the first upgrade!!    Always solder all joints as possible too.  In this setup, the heating of the Tamiya connectors and the power crimped blue spade connectors is way bad...  

Now this is cool!!!

With all those bad connections and wires all over the place giant voltage spiking rules!!!

Here one can see the spikes set off by the PWM power limiter and normal PWM:



If we drill into just one spike we see...



The spikes are clamped totally at +23.2V and - 0.3v.  The super uber TVSs that clamp so fast you need a quantum physics paper just to predict their speed!!    The scope is set to a full 10nS peak detect here in the big picture too.  But "NOTHING" is getting through!!!  I think this is a major key into why Panther platform's real failures due to "electronic weakness" is simply zero!!!!!!!!!!!!!!!!!!!!!!!!!!!!

We can estimate the power dissipated in the TVSs:

The back spike is ziltch compared to the forward spike...

The forward spike is:

Say 38A at 23V for 2.3uS or  38 x 23 x 0.0000023 =  2mW/each.  At 10kHz that is 20W!!!

Thank goodness they are rated at 1500W        

In my test case here though under PWM they are dumping a lot of power into the unit.  But in a real gun with far far less inductive wire it is a don't care(let alone the low duty cycle).  But it does show the massive problems those giant TVSs are solving for us!!!  

So I need to work on user programing stuff next...    

Gandolf

[skag187]

so whats new with the Lion?
how goes the development?
when do we get em?

[Gandolf]

so whats new with the Lion?
how goes the development?
when do we get em?

Not much at all "new"...    I have been pretty swamped with orders and zero time for new stuff...  

how goes the development?

Very good!!  I have been sending out prototypes to "real" programming gurus to see what they can make of it!!  A few snags so far   But working on that...

It is a really tough 'slow time' right now.  But no time at all to 'back off' 

when do we get em?

GOK...  (God only knows)...  It was a big hardware leap that seemed fairly simple really...  But the software side to make it cool super is taking longer...

I don't think at all that we bit off more than we can chew...  But it is a "giant" chunk of meat that we need to work out  

Newer high voltage 3034 FET things have also added new opportunities......

It is always hard to say when to "pull the trigger"....  But if the product is in major flux...  You need to wait it out always...

Gandolf

[skag187]

I don't suppose there is/will be any sort of SDK for it would there?

or is all of the software like one huge txt file?

[Gandolf]

I don't suppose there is/will be any sort of SDK for it would there?

or is all of the software like one huge txt file?

There are five text (C) files really  

http://extreme-fire.com/Lion/Lion-1020/

But all the *.h files just have hardware interface functions or do common tasks.  Sort of like "toy boxes"  

That makes the main program far simpler and easier for C programming types to play with.

The whole "real" program of the moment is right here!!

Code:

//MAIN OPERATING LOOP//

CycleLoop:

//  Loop time control
//  Sync cycles to Real Clock every 1mS
while (CycleTime == RealClock) {;}  //  Hold till next clock cycle
CycleTime = RealClock;  

//  Find motor run time
if (MotorStatus == 1) {MotorRunTime = RealClock - MotorStartTime;} else {MotorRunTime = MotorStopTime - MotorStartTime;}

//  Find pre-cocking time
if ((BrakeStatus == 0) && (MotorStatus == 0) && (TriggerCounter == 5))
{PrecockTime = MotorRunTime - PrecockTriggerDelay; ShotTime = MotorRunTime;}


//  Error Handling
if (Error > 0) {LED(2);} else {LED(1);}
if (Error > 1) {StoreHistory(1,Error); Alert(Error); Error = 0;}
// 1 = Voltage droop
// 2 = Voltge droop shutdown
// 3 = Over peak current
// 4 = Over running current

//  Check for excessive battery voltage loss and running current
CheckActivePowerLimit();
CheckMotorRunningCurrent();
CheckShutdownConditions();

//  Check for Trigger
TriggerVoltage = (GetVoltage(Trigger,0) * 5 / 4);  //  Correct for 5K protection Resistor
if (TriggerVoltage >= 6500) {TriggerONDebounce++;} else {TriggerONDebounce = 0;}
if (TriggerVoltage <= 4500) {TriggerOFFDebounce++;} else {TriggerOFFDebounce = 0;}
//  Turn motor on
if ((TriggerONDebounce >= 3)  && (MotorStatus == 0)  && (Error == 0))
{TurnMotorOn(MotorSpeed); TriggerCounter++; TriggerStatus = 1;}
//  Power Start
if ((MotorStatus == 1) && (RealClock <= MotorStartTime + 10)) {MotorPWM(255);}
if ((MotorStatus == 1) && (RealClock > MotorStartTime + 10)) {MotorPWM(MotorSpeed);}
//  Turn motor off
if ((TriggerOFFDebounce >= 3)  && (MotorStatus == 1) && (TriggerStatus == 1) && (RealClock >= (MotorStartTime + 20)) && (ShotTime < (MotorRunTime + PrecockTime + 10)))
{PrecockStartTime = RealClock; TriggerStatus = 0;}

if ((RealClock >= PrecockStartTime + PrecockTime) && (MotorStatus == 1) && (TriggerStatus == 0)) {MotorPWM(0); Brake(1);}  //  Stop Motor
if ((RealClock >= BrakeStartTime + 100) && (BrakeStatus == 1) && (TriggerStatus == 0)) {Brake(0);}  //  Turn off brake


// OutputLCD();


goto CycleLoop;

return(0);
} //  End of Main

There actually has been a lot of work this week!  There is now a 20.0V capable Lion version as an experiment for those that can't get enough LiPO batteries stuffed into their guns.  Two other real programmer types are also working on things.   And I am working on getting another care package to a guy in Japan.

I am not sure they are all totally interested in airsoft though.  A low voltage super extreme well protected half bridge with giant CPU ability and open source attracts some other users too  

Gandolf

[octoberust]

 Whaaat kind of users?

[Gandolf]

Whaaat kind of users?

A lot of "PH.d" and "Dr." 'university' types

The lion is actually a very hard line low voltage but super current application 1/2 H-bridge.  Giant computer control!!!  It is also very well tested in the background.  That will attract "others"!  It's TVS protection is a bit ahead of them!! 

They are 'up to something' 

They keep a darn good eye on us "ground feeders" for when we hit 'pay dirt'!!!      

Their help is always "golden"!!!  They have a giant eye over such things to help keep us on the best track to take forward!!

No worries...  Us "super switchers" may get a little outside attention.  But they all "feed back" to us too!!!!

It's all super good!!   

I hope one day "one", may 'take off' with it all!!! 

Then, I might truely be able to "retire"

Gandolf

[octoberust]

 I don't completely understand the applications in the computer realm you are talking about (always willing to learn) but I hope you find and develope, with great success, the product that will be your "retirement" solution. Best to ya!

[Aranarth]

Gandolf, would it be any help for you if i create a "minimizer" for the program-code? It would kick out all comments and empty lines and unnecessary whitespaces through which you can gain more programming-space.

[vattern]

The compiler already does all of this, only the actual code gets converted to a hex file for programming

[Aranarth]

Oh, yeah I could have thought of that. I just didn't cause at my daily work I have to deal with code that doesn't get compiled.