CAN handling requirements for Master in a BMS

methods

1 GW
Joined
Aug 8, 2008
Messages
5,555
Location
Santa Cruz CA
Thanks for reading.

Assumptions: We are talking about a distributed BMS, not a monolithic BMS. In this case we have between one and dozens of slave modules embedded in cell groups of 4-12S, communicating over a private dedicated isoSPI bus, and the Master is charged with directing the slave units (when and how to balance, what to report, etc) and interfacing with the outside world. We assume that the Master buffers/protects the Slave modules from the open CAN buss (Where many adversarial events can occur) and the master has sole control over the primary Contactor, Precharge circuit, and carries such responsibilities as reading current sensors, monitoring leakage currents, accepting/transmitting emergency communications over a CAN bus, and broadcasting standard telemetry data.

With that assumption, lets assume worst case:
CAN buss running at 1Mhz
Extended packets or proprietary protocol
Busy primary CAN bus... lots that needs to be filtered out... consider it an adversarial CAN buss where an idiot wants to flood us, trip us up, etc. Assume it is wired into WiFi straight to North Korea. :mrgreen:

The Question high level:
How many object types would the Master have to receive in real time?
How many object types would the Master have to process non-real time?
How many object types would the Master have to Transmit: Real time, broadcast, and asynchronous?

Constraints
We are trying to implement a LOW COST solution that covers a broad range... so no "ultimate solutions"

Transmit hardware level
Do we need a $1 super simple CAN chip with a basic 2 level deep buffer with a little masking and filtering... or a very fancy ?($7) chip that handles everything under the sun?

Intermediate
Do we need a chip (uController, FPGA, or other) between our CAN chip and our Processor to FIFO and unpack complex messages... thereby allowing the primary MCU to be more deterministic and focused on the job of BMS'ing.... or... do we try to keep communication complexity down far enough to actually handle the CAN business right on the primary MCU (where MCU would need to handle all the slaves and peripherals... AND ... the CAN bus)

Primary MCU
I believe that to ensure we glide through qualification that the Master should be deterministic... at time 0... or time 1000000000.... I can tell you exactly what it has done, is doing, and will do next (yes this is easy to accomplish with a state machine and time slicing... where one time slice is dedicated to servicing interrupts)

Go big, or go home
If I try to handle the CAN on the MCU I must strictly limit the amount of communication I tolerate and I will need to use a higher end CAN chip. In this case I would guarantee that I respond to an EMERGENCY object within Xus... and that I would accept "requests" in a lossy-queue or asynchronous matter. I would need to only broadcast per-programmed packets and I would not want to respond to data requests on any sort of recurring basis. I would filter nearly everything out at the hardware level and I would bias toward ignoring CAN and focusing on Battery state and safety.

Going big means I use either a basic or complex CAN chip along with a (pretty small) dedicated MCU which does nothing but handle CAN. My primary MCU would update this chip with "fresh data" as it saw fit, accept emergency interrupts from this chip, and read deep buffers off the chip asynchronously. The CAN Buffer chip would be tasked with all the unpacking... such that data is "ready" by the time the primary MCU gets it.

So....
I have seen an implementation or two... but there are dozens and dozens of OEM's out there who do all sorts of crazy things on any number of CAN busses.

Does anyone have direct personal experience with arbitrating a situation like this?
I know how I would do it... and how others have done it... but I am also prone to steer off into the weeds and do geek stuff that others scratch their heads about (blame aerospace).

My instinct is to use the best CAN chip I can afford, stick a tiny uP on it to implement (say CANopen or ISOblahblah) and keep my primary MCU focused only on BMS duties in a deterministic way.
Second choice would be to run a really good CAN chip and bump my primary processor up to something faster that can handle both duties.

Simple is better.
Simple is cheaper.
Less is usually enough.

I am really only producing a "fill the crack" distributed BMS that AT MOST would serve as the equivalent to a "Demo Board" for OEM's developing around LTC based slave systems... but at worst would need to be good enough for Experimental Flight, very large batteries stored in the home, of course Cars and vehicles of every shape and size, and motorcycles/extreme bicycles.

thanks,
-methods
 
Good Arduino thread about the DUO supporting CAN functionality... such that only a cheap transceiver chip is required... and the DUO can act as the CAN interface, or at 84MHZ, both the primary Master and CAN interface.

Arduino Forum Thread on DUO with Supported Build in CAN functionality

I stumbled onto that while trying to bound the range of available CAN controller chips.
Of course you used to need:

Transciever
Controller
Arbitrator
Primary MCU

Then things got faster... maybe drop the Arbitrator
Then CAN controller got built into MCU... maybe drop Arbitrator and controller

So I spend a bit more and use a much more powerful MCU... and a dollar transceiver.
There are other downsides to this... like the DUO AFAICR runs only up to 3.3V so I have to do a bunch of bullchit level translations to interface with 5V externals. It also means my ADC only scales up to a few volts... these sorts of obnoxiousnesses can add up quick.

I am still a 5V MCU kind of guy
Stick with what is out there... or find out late in your design... that all of a sudden you need a bunch more stuff on your PCB :roll:

we will see.
I will fire off a list in a minute here. Kill off a few options... like every single bare bones controller out there (like the Microchip MCB25XX.... which I have worked with before).

I want big buffers
I want all sorts of masks and filtering and interrupts and multiple queues and ... yea... that sort of stuff makes my job a lot easier.

All the better if it has a built in transceiver.

There is a bell curve with packing functionality... at some point having a super high pin count tight pitch part becomes more problematic than just dropping two 8pin parts and a few traces... We will see.

-methods
 
Yep... we win again.

Anyone who still harshes Arduino or does not support open source or who covets there shit as all "TOP SECRET" is a retard plane and simple. Modern day neanderthal.

Just look at this: https://github.com/collin80/due_can

Look back at that thread I posted... spanning 5 years.. while dudes ground this out for the betterment of all. :shock:

Look at this piece of gear... 84Mhz...
https://store.arduino.cc/usa/arduino-due

You telling me that is not pure awesome? That there are thousands and thousands of people like me who want to work together with you so that we all dont have to re-invent the wheel ever time we are going to start a new project???

I think only people who are collecting a nice fat salary think this way. (negative about Open Source)
People who dont care if they and others have to do the same work over and over... as it is paid work...
People who are super specialized in this chip or that chip... coveting IP.

(loud fart sound)

All I know was that back in 2001 I was programming 16F84's in assembly language and dreaming that one day toasters would have uControllers in them... Now in 15 minutes much of my job is done in that I can buy a $50 board off the shelf, load software for half an hour, and have a functioning starting place for a CAN implementation. The only price? Give some back... find a bug... improve on the code... write an example... anything really. Just push for the cause and bring more folks over.

living the dream son.
Support Open Source or eat a hot pile.

If you must... refactor into something your business guy can patent troll/whore or whatever goes on to make money (which I want to know nothing about)

-methods
 
Wow... as I investigate developments in CAN over the last decade... it seems like I really did it the hard way!

This always happens.
Engineer devotes time and develops ways and methods
Technology progresses
Things get much easier
Previous design seems inferior...

Thats where perspective comes in. I just keep reminding myself... "this stuff didn't exist... this stuff didn't exist.."

Ok - so when I was playing with CAN there was a 2 byte deep buffer. It was SUPER STRESSFUL worrying about worst case packet response.
Looks like 64 bytes is now "no big deal" for a CAN controller.

Another thought... is architecture... if we want to leverage others work.
All the layers are implemented here and there in different ways.... but if one intends to shoe-horn any of those into an existing deterministic design... thats where the stress comes.

If I just push all the CAN layers offboard... I can be pretty inefficient... and make minimal changes to off the shelf examples.
Nothing I would love more than do dive into CAN for 6mo... but eh... let me tell you... that shit does not pay the bills.

What pays the bills is me completing a schematic
A completed schematic allows me to estimate time and materials
Time and materials allows me to make proposals
Proposals pay the rent.

To get to the schematic I need requirements
Requirements lead to a System Level Architecture
Architecture breaks down into components
Components get spec'ed... down to exact part numbers, availability, cost, peripherals required, board space
Somewhere in there a schematic is Chicken-Egg created... and the Produced Cost Pressures... usually drive what the schematic looks like.

Ok - CAN
One of the last 3 pieces of the puzzle... Gotta support it... gotta be industry standard... gotta hit 1Mhz... might want 2 CAN ports... cant disrupt my deterministic code... cant require $20 worth of chips... dont need a 200pin uController... dont have time to write a CAN stack from scratch... gotta lean on whatever work is available... gotta develop in a way that I can give a snippet back without upsetting customers...

winning

-methods
 
Oh yea... it all comes pouring back in....

The CAN WILL be off-board.
Contention of resources - Timers
Determinism - Requirement for Interrupts constantly

Yep - timers can be worked around (tho I prefer to have a full set when solving a problem. 20 minute solutions turn into 2hr solutions when you have to play silly resource games)

Yep - Code can be written to tolerate interrupts at any time... the functionality is not the issue... the qualification and proof of the design IS the issue.

Any Mission Critical Safety Subsystem which is responsible for human life either directly or indirectly must be proven to be safe.
The proof of this safety can take 5 minutes or 5 years...
The proof for a deterministic system requires only proof of determinism... and some basic calibration type stuff.
The proof for an interrupt based system requires actual bounding and testing of full spectrum worst case... and this must be repeated EVERY TIME YOU CHANGE THE CODE>... even adding a printf (and for damn good reason)

Listen kids...

If you are developing early code for Battery systems... listen to Uncle methods.... yea you might get away with ANYTHING today... but you will pay the price later... when regs roll out.

When you are thinking about navigating regulation you can approach it 2 ways:
1... wait for chapter and verse... and try to get it right. (phart sound).
2... just use sound principles in your design which you can prove to be true and notify others that your code is deterministic, your hardware is calibrated, and you can prove it easily.

Dependancy

Its about being only dependent on yourself (and the power rail of course...) and having any sort of external dependency. Even when reading a Hall sensor... or any sensor on SPI... lets say it takes anywhere from 1mS to 3mS to read the sensor... in a deterministic system you pay 5mS for that all the time every time. A bit less efficient... but always the same... and you can neck it in as you develop confidence that your externals meet spec.

Change your thinking for high reliability. We are not writing flogger video game in Java to impress your little brother. We are creating a robot which can kill us and our families or protect us diligently.

Ok.. I am avoiding research... so much easier to run mouth than to read datasheets... but I am not getting paid right now... so pound sand.

-methods
 
I dont know about you... but as I get older... and my mind fills with more and more and more cruft... delays are incurred.

I can recall just about every bit of minutia I have ever been subjected to going back to about 1980
Accessing that minutia - especially the minutia around times of great pain - takes longer and longer.
A self protection system - that's what a therapist would say.

But - with triggers and queues... I can regurgitate almost anything verbatim. Right down to conversations that happened in a hallway 15 years ago, what I thought, what I heard, what I said, what I saw.

CAN
Humpph
I have a lot of resistance around working on this. I have to milk it out of my brain :)

Under pressure I lock up and send out FUD. I blame that on a weird childhood and then 10 years working under threat of death (I mean that... )
But... when I settle down... imbibe coffee... fall into the mindset that I am going to implement... complete confidence comes back and all the details are available.

Its extra hard when arguing with other engineers who have invested time in a fruitless path. They passionately argue for whatever unreliable thing it is they want to do. I avoid the debate. Best to just do it right - even if it takes 5 years.... then later nod my head back and say... yep.

SO

My brain says that even if BOM cost goes up by 5% , efficiency goes down by 10%, board spaces goes up by 1sqInch ... savings will be realized at the Software, Firmware, Qualification, and Production testing phase. Big savings. Recurring savings.

One of my first big projects was trying to develop a flexible R&D tester, that was REQUIRED to change almost daily, but had to be qualified before it touched any critical hardware.
The solution was to break the system up into individually qualified parts and prove that one part could not affect another.
In doing that I could change certain sections in anyway I wanted... and leave other sections untouched...
Guarantee Timing - that's my advice. Thats how your unit tests get REAL SIMPLE.
Guarantee that you can document deviations reliably... meaning if you can... record everything you do and save it to a file (feedback loop... for every DAC you have an ADC and a time stamp)

So Sim-Po.

methods - GO READ F'ing DATASHEETS. GET TO WORK BUM

-methods
 
Yea... right ... like we are going to stuff this 10lbs of shit into the 5lbs of available space on our microcontroller

http://www.canopenstore.com/canopen-communication-stack-comparison.html

YOU CAN DO IT.
But you can also pound a traffic cone into your butt.

Whats much easier... is to excrete something down onto a purpose built subset of hardware... add a few buffers... an SPI port... and just calculate the worst case read and write... and stuff that into the state machine.

Yeppers
Argument done.

Sucks working from home without 30 other brilliant people around to bounce ideas off of.
I have to bounce them off the ether... and that is what you see here.

We are no longer debating stuffing a CAN layer on our primary... it is going off board.
This will allow us great flexibility in the controller used for our Master, the code for it, its determinism, ...

Same way I did it in the epic year 2000.
One uController for communications... one uController for controlling hardware.
The PIC16F877
Prior art maFuckuz

Robot on floor.JPG

Even with raspberry pi and the equivalent of laptop processors available on a chip... I would still select a simple microcontroller running an *actual* real time set of code. Running bigger and bigger processors just allows you to (pretty much) guarantee 1mS or 100uS timing with jitter. I want to guarantee 1uS or better with no jitter. That will allow me to unit test over a time period (once) and then point at the code subsequent times... and say: "If the hardware does its job, then operation X will happen at time Y, and there is nothing short of physically attacking my hardware which will impact that"

-methods
 
That way I dont have to point at the operating system... and worry every time it is updated...

I point at the hardware and the state machine and the lack of interrupts.
Yep - lack of interrupts.
We will navigate the loop so fast that we will get away with out being interrupted.

84Mhz... jeBusKriste
How many RISK instructions is that per cycle?

Of course... when we release... we scrub away the boot loader and Arduino and port down to native code.
Used to go all the way to assembly... today we can go down to C... tomorrow we will be able to leave it at Arduino

Arduino RTOS FTW!

-methods
 
Ok - there will be interrupts of course... but only on timers and with a fixed response

Set timer
Walk away
Timer eventually fires and sets status bit
We check status bit when we damn well feel like it

All timers run all the time - eat the handfull of cycles.... fill out the time in the pie

Like going to the library
All the books are there
A few are checked out
Grab one that is there and set it
Return it by the time stamped or earlier
Get to go to the library again

Dont return your book on time
Death by librarian breath

So... deterministic interrupts... and I will turn those bastards off while changing states or doing anything mission critical.
Do not interrupt uncle methods while he is suppressing future fires!

-methods
 
So back to the problem:

How small of an MCU can I use to support the CAN controller and buffer data to my primary MCU
How small of a primary MCU can I use to support all my IO (as there is not much processing to do... just reliable processing)

Speed on the CAN buffer
I/O on the primary
Cost on both of them
Not really worried about footprint
Peripheral dependency is important... run on the internal clock for the CAN buffer... need precision for the Master so we can show determinism across temperature swing.

We can just oversize... so at this point there is a Y in the path and its up to the engineer:
A) Break out simulators, estimate bandwidth, consider application, determine minimum timing....
B) Look at the economics of controllers, find the most power for the best price, make sure that is faster than absolute worst case

I am a B sort of guy... but if I were at the labs or university I would be the A sort of guy.

Remember... all we gotta do is put a schematic together... down to exact part numbers... to calculate a BOM and produced cost... to ask for a budget... to pay the rent.
If nobody wants to pay we set it down
If someone later wants to pay - work done... minimal changes needed.

If methods finds out that someone sat back saving money while he was BROKE and his kid was wearing socks with holes in them... hoping that methods would do all work for free... then just give it to employeer so you can profit... then method leaves to go be hungry again? Hrmmm... in that case... methods flips the bird. 8)

Its not a question of whether I have the chops to do it.
Its a question of whether I have the financial security and social safety to focus on it.

I'm tired of working in semi-hostile enviornments
I'm tired of being broke

I am not tired of being PC... and after 10 years in government of course I know how to behave... but right now we are not at work. We are in my hobby shop... and you dont need to read this... so I can talk about sticking traffic cones up my butt and its funny haha.

Not funny haha at work... depending on the amount of government funding you take.
More money, more PC

OMFG let me tell you about working at Zero Motorcycles.
I would guess.... there is very little to no government funding there. :shock:

-methods
 
This dude tried to help me pee in the bathroom :shock:

I was like... "uh... after work ok? This is a professional environment!"


bizarro-roby-bearded-lady.jpg


-methods
 
Why we hire for diversity:

Three options

A) Because the government tells you to do so if you are taking government money

B) You don't because you don't have to and you are all wound up and uptight

C) You do because you get an incredible value from doing so




I have found, after working 10 years in government and 5 years in the bay, that my best colleges were ... living an alternative lifestyle.
Ok... explain that.

Well the explanation that was true a decade ago (and is less true now as we assimilate) is that people who have had to fight to be accepted often display exceptional performance.
Thats kind of capitalistic - lets look at it in open-mindedness

People who explore alternative lifestyles tend to be more open minded and and can jump the gap more easily
Truth

Thats not to say that the most rigid and uptight people I have worked with do not have complementary skill sets... some of the most reliable engineers I have worked with were hardcore religious. This brings a different sort of value to the table.

The trick?
To manage to put together a team of diversity which leverages the best people can offer... and find a way for them to get along... I mean REALLY get along... and not just pretend to get along between 9 and 5 then speak ill of each-other when they get home.

That's diversification.

On my team - you can be non-gender specific, hardcore Muslim, Mormon, 7th day, ... you can use drugs off duty (if it does not affect your performance!), you can speak any language (so long as we can communicate efficiently), you can be communist, socialist, an InfoWars fan... you can street fight at night, go to SF and Power Exchange at night... you can wear a dress to work or leather pants...

Whats important is our ability to produce.
End service announcement.

-methods
 
OMG I am so tired of working for free...

I even went across the street and changed out the starter on my neighbors busted old greasy truck for $80 bux just to feed my capitalistic hunger for reimbursement for my work. It was a nice break.

sigh... CAN methods... research what parts you are going to spec for CAN support.

(my kid is playing with Construx on the floor... that looks so much more interesting right now...)

current efficiency: 30%

-methods
 
Ok - down selection time... we all do it different and it really makes little difference to me... except for cost and time in development...

Going with Atmel because they are friends with Arduino
(yes I am an expert in TI, PIC, and any uP of course... just going with the flow... they all work the same... they all cost the same... we NEVER jump on the newest latest and greatest... we stick with what we know works, is in full production, will be supported moving forward, is cheap, is supported... Only a fool tries to ride the wave of tech as it first comes off the line :roll: )

Both for primary and for CAN buffer
(Terms: Primary, CAN buffer, CAN controller, CAN Transceiver)

CAN buffer might as well have CAN controller built in... and can be 3.3V... and just needs a cheap RX/TX... then we can try to leverage some existing code in the sphere.

Primary - I want it running at 5V and it has not avanced feature requirements other that what a Mega2560 can do. Best if it has multiple SPI ports, multiple hardware UART, multiple low power modes, multiple PWM, plenty ADC, reasonable footprint (no f'ing ball grid arrays... come on man... I want to rework this stuff when required... and get them produced cheap... KISS... 0805... )

****************
Damn the ATMEGA2560's are still 10 bux! Forget that for primary.... I am on a budget!

Er... I need to research low cost 3.3V to 5V converters... so much clutter... so much mess.
I get it... everybody wants to run 3.3V and lower. Everybody wants to run bga... sigh...

I can make it work on a 328P.... TWO BUX SON!
CHEAP!

Ya see... are we driven by data or driven by economy?
Economy when the rubber hits the road.

Off to a meeting... but going to find the best value Arduino supported Atmel (or other) chip and slap um on the board.
Getter done!

-methods
 
Don't you need the can nodes isolated?
 
Excellent question.

My slave devices are working on isoSPI and have no CAN.... so no worry about nodes on the stack.
My master rests on battery ground (or parts of it do... we will see how the noise goes...)

I have isolated CAN before in a distributed BMS design and it resulted in lots of noise shooting through. I used isolated DC-DC supplies and high speed digital isolators.

My immediate answer would be YES... it should be isolated if possible... but that kind of thinking stacks up cost.
I am going to bring a big thick ground up to the Master and just reference it.
I dont think anyone else in the system should be riding anywhere above ground... if they are on 12V... and it is actually isolated... they can deal with it on their end?

Suppose I should read the ISO requirements on that.
I am guessing... if I am touching HV ground.. then I need to be isolated from the 12V ground...

Yes.
Excellent question. Thank you for that.

-methods
 
Btw...

I am super old school and think ground should be ground should be ground - at some point in the system.
I would tie my HV ground to my 12V ground if given the choice.

Isolated always sounds great... then weird stuff starts to happen... high speed shoot through noise.
At least when it is all hard tied together you know what you are dealing with and can snub it.

-methods
 
No. Just... don't.
Traction pack must be isolated, both terminals. You can tie the 12v gnd to the chassis, but not HV. Before starting *every* DC fast charger sends a 500v pulse to measure if both terminals of the HV are properly isolated from gnd. If not, it won't charge. Thats how important it is.
 
Lol... thanks marcos.

Here is a good Digike write-up of it.
https://www.digikey.com/en/articles/techzone/2012/aug/can-bus-taking-a-larger-role-in-evs-and-phevs

I used the Avego 1Mb parts along with a CUI 3W isolated DC-DC last time.
Ah man... do we HAVE to isolate :cry:

-methods
 
sigh...

Adds cost in the form of isolated DC-DC's and high speed isolators
adds pin counts to connectors
Forces PCB to be broken up into sections

Man... if you just had not of said anything :D MAYBE we could have got away with just tying it all together.

So... how about I just cut the ground wire on my high speed charger :twisted:

-methods
 
and....

You just said we have to isolate from Chassis...
Not that I have to isolate 1200V ground from 12V ground 8)

-methods
 
Ok... Ok...

http://www.diyelectriccar.com/forums/showthread.php/grounding-chasis-95163.html

Random people on an EV forum concur...
so.... (methods kicks a rock and shuffles his feet and pisses and moans...)

I guess it is so.

So this may give me the perfect excuse to drop support for the 116V Zero contactors... as they would foul my ground.... otherwise I would have to isoalte the mosfet drivers and double the I/O on them.

Done.

No more support for 116V contactors.
We will support any contactor 30V and below (so basically 12V and 24V)

When Zero skipped the 12V battery in their system they opened one hell of a can of worms which trickles down in all sorts of ways.
I think it makes sense not to support it.
Lets support COTS.

-methods
 
Since we are on the subject of Isolation these buggers are not cheap

http://www.mouser.com/new/broadcom/avago-acpl-c87/

But others are.

For measuring Precharge you will need a stack of very high precision, very large resistors.
Those will be referenced to Battery ground so if you dont have a small onboard DC-DC... start scratching your head.
I posted plans for a pretty good one.... but only up to 150V
If you know your voltage it is very easy. If you try to support a wide range of voltage the wheels fall off.

There are various methods of measuring voltage in an isolated way - they get a little harder when its high voltage - they get a LOT harder when its a voltage range spanning 2 orders of magnitude.

Reasons like that... are why you dont see "general purpose" BMS units at K-Mart lol.

-methods
 
P.S.
Here is a tip that no one will find

We dont actually have to accurately measure high voltage to do precharge.
We only have to accurately measure the differential voltage between the contactor terminals :!:

So we must tolerate 50V or 500V or 1200V...
But we must only resolve accurately say... 12V

That simplifies things... but one would still want to measure full stack voltage directly and not just trust the slave modules... IMHO.

-methods
 
Last post... time for bed.

Since Marcos kindly provided a requirement for us (eh hem...) we can now do some System Architecture and eliminate some paths forward:

(Remember... we are not copying any previously existing design here...
WE ARE DESIGNING TO A SET OF REQUIREMENTS AND THERE ARE ONLY SO MANY WAYS TO SKIN A CAT...

* CAN bus must be isolated... so no built in CAN support on uControllers
(Edit: Tho of course this would work if we ran the uC off the 12V buss with an isolator to the main... and those DUO chips are only $3...
* Since we need to do our dirty work on the 12V ground... no Contactors that run off of battery voltage (sweet!)
EDIT: Unless we want to add $30 in complexity
* Since we need to perform Precharge, we will need to reach into the ether and figure out the only 3 ways there are to do that in an isolated way
EDIT: As the days go by my taste for supporting multiple applications is draining away... with BOM targets...
* Since (some random guy) said we want to support 12V to 1200V.... we wont be fooling around with an onboard DC to DC (sweet!)
EDIT: Yea... meh... job is 10X harder when we dont build to a specific.

So we have eliminated two sources of potential IP issues by eliminating the way Zero Motorcycles did it

Since we do not know what our final voltage will be... we wont be doing it how Tesla did it.

This means we will be employing "Patrick's method" - aka "methods" - and our design will be our own.
Lawyers may not think so - but they are not engineers (except for a few and I am scared as hell of them... patent attorneys) :shock:

I know of only one... and his house was full of dark rich wood and he had many expensive toys.
Yes... we want nothing to do with having him on our side of the table... or the other... as HE makes all the money!

When I see cash money american in the bank... we will get serious.
Until then ... we do it the LukeMan way:

* Send out 5 bad ideas that we think may work but probably wont... but could
* We hope one comes back... if it does... WIN
* Meanwhile we do it the way we know it will work

On race day... WE WIN!

lol... just kidding.

-methods
 
Back
Top