Familiar with AVR communications? Let me pick your brain please

Hello everyone, I'm trying to create a system to sync up the RPMs on two single cylinder two stroke infernal combustion engines. These engines are currently carbureted, but I have some EFI kits I'll eventually be installing. They will eventually go into an experimental ultralight MODEL aircraft.

I have the outputs from the generator, and and a hall effect sensor installed into the crankshaft housing.

I built a circuit to isolate and rectify the sensor outputs, and read them and convert them into RPM's. Currently works at about 2hz which isn't near fast enough, but we're getting there.

I'd like each sensor to have it's own AVR, and all of the sensors communicate with a host controller, which does the math to bring them to sync and compare the redundant sensor data, and then outputs desired RPM to each of the AVR's handling the servo based throttle control.

The EFI will also have a bunch of sensor information I might be able to make use of, so having a surplus of communication nodes on the host controller will be useful.

I've been brought in to help out with this project, and there have already been a few people who have tried to get things done already, so I'm taking stock of whats available and going from there.There are a bunch of ATTiny45s lying around, but Im a few years out of date as to what is the new hotness in AVR`s.

That is the background, so essentially my question is what would be a good communications protocol choice that is fairly easy and inexpensive and light weight (in terms of physical mass) to implement.

attiny`s using USI talking to an ATmega?

new hotness version of attiny using CanOpen or CanBus shields to just spam the bus with all the different sensor data and an ATmega grabbing that data as fast as it can and processing it?

AT328 using I2C to connect to the 4 individual UARTS on an ATMega?, then using something else to send the data out to the throttle control servos?

Arinc 664?

Plane Jane SPI with multiplexed shift registers?

The max RPM's of the motors are 6800 rippums. Therefore the counting of the RPM's and getting an accurate number doesn't need to be ridiculously fast. The communications of the RPM data shouldn't also require a really high speed data network. I'm not sure how fast the communications are going to need to be in order to really get the Motors to sync up, but their change in RPM isn't incredibly fast so I imagine I won't need the most blazing protocol.

I would also like to stick to the design mantra of use lego blocks, so implementing this with off the shelf available parts would be ideal.

The wiring is fairly near to the ignition coils, so I was leaning towards canbus as it's pretty reliable in noisy environments.

I think that's enough info to make an informed decision about which protocol to use, let me know if you need any more info and thanks for dropping wisdom on me. Much appreciated.

Have you looked at the licensing agreement for the AVR chips? I think they specifically prohibit use in safety critical components like this.

Delta_G: Have you looked at the licensing agreement for the AVR chips? I think they specifically prohibit use in safety critical components like this.

This is just an exercise in engine control automation, nothing safety critical about it.

cedar_door: This is just an exercise in engine control automation, nothing safety critical about it.

Didn't you say in your Original Post that it is for an Ultralight aircraft?

I can't imagine why your design horizon for something like this should be limited to things that happen to be "lying around". Just get the right thing for the job - so what if it costs an extra 20 bucks?

...R

Robin2: Didn't you say in your Original Post that it is for an Ultralight aircraft?

I can't imagine why your design horizon for something like this should be limited to things that happen to be "lying around". Just get the right thing for the job - so what if it costs an extra 20 bucks?

...R

Gotta start somewhere, might as well start with what you've got. TX speeds here are glacial compared to what modern uC's can do.

The application isn't something that currently exists, but is kinda similar to an ultralight in that it has gasoline engines.

Does that make sense? Why would I use some "right thing" when an ATTINY wired to a shift register will do it just fine?

cedar_door: Does that make sense? Why would I use some "right thing" when an ATTINY wired to a shift register will do it just fine?

Because when you half-ass something that flies people could get hurt.

These posts are not helpful, gentlemen.

We're talking about AVR communications, not whether or not this project which was left intentionally vague in the description is possible to make intrinsically safe.

Everything with engines and motive force is potentially dangerous. If I was uncertain about any elements of this project in regards to safety this thread would contain very different questions.

Suffice to say every possible safety consideration has been implemented in the design and furthermore, everything already works and flies. This is just an idea to attempt to get more thrust out of the prototype.

Now, can we please get back to the topic on hand?

Suffice to say every possible safety consideration has been implemented in the design

No, it is not sufficient to say that if your whole point of the post is about how to take short cuts on safety. You can't say, how can I short cut safety on this and at the same time claim that you have implemented every safety consideration. One of those is by definition a lie.

Look man, do what you want. It's your ass that is responsible if something happens. But don't ask us to get involved in creating safety hazards. We work on hobby projects. We don't like to get involved with things that could get someone seriously injured or killed.

Please also don’t ask us to get involved in breaking license agreements for products that some of us use to make a living. There’s more to this than your little project.

Delta_G: No, it is not sufficient to say that if your whole point of the post is about how to take short cuts on safety. You can't say, how can I short cut safety on this and at the same time claim that you have implemented every safety consideration. One of those is by definition a lie.

Look man, do what you want. It's your ass that is responsible if something happens. But don't ask us to get involved in creating safety hazards. We work on hobby projects. We don't like to get involved with things that could get someone seriously injured or killed.

oh man, you are something else.

How are 2 AVR's communicating a "short cut on safety"

No one is doing anything unsafe, or breaking any license agreements or anything of that nature.

What is the point of looking for boogiemen under every rock?

In reality upgrading the avionics is a huge upgrade in safety.

Now please, if you are familiar with some triple redundant one way serial communications protocols, post them up and I'll read up on them. Or if you have anything helpful to say, please, I encourage the discourse.

But getting into a thread and saying I don't know what you're talking about, but I don't like it, so I'm going to ignorantly attempt to poke holes in unrelated things isn't helpful, and it's kind of annoying.

@Delta_G has concerns. I do too. We will start with alleviating some concerns.

You say you are planning to control the throttles using servos. Is that how the throttles are currently controlled?

You want the throttles controlled by servos driven by AVR processors. Is that how the throttles are currently controlled?

[quote author=Coding Badly link=msg=3443464 date=1507665063] @Delta_G has concerns. I do too. We will start with alleviating some concerns.

You say you are planning to control the throttles using servos. Is that how the throttles are currently controlled?

You want the throttles controlled by servos driven by AVR processors. Is that how the throttles are currently controlled?

[/quote]

Yes. No. They are driven by an off the shelf futaba model plane kit. The avr will be adjusting the futaba control systems throttle trim.

This is not a control situation, it's a fine tuning. An adjustment. The spragg clutches are disconnecting motive force too often and I would like to see if I can reduce that reduction of power state.

cedar_door: Why would I use some "right thing" when an ATTINY wired to a shift register will do it just fine?

If the Attiny does the job then it is the right thing. But the way you referred to it in your Orginal Post made me think you were just using it to save a few cents.

On the other hand, even if the Attiny can do the job it may be easier to develop an Arduino project on one of the more standard Arduino processors.

...R

cedar_door: These posts are not helpful, gentlemen.

Then I will post something that is helpful...

We're talking about AVR communications ... which was left intentionally vague in the description ...

"Vague" and "communications" are mutually exclusive. (You not understanding that is my primary concern.)

The avr will be adjusting the futaba control systems throttle trim.

I was trying to ascertain what components were involved in communications (are there two AVRs at the end of communications lines which happen to be running servos). Now, instead of multiple AVRs performing various duties I'm left with "the avr" and it will be magically adjusting a trim.

This is not a control situation, it's a fine tuning. An adjustment. The spragg clutches are disconnecting motive force too often and I would like to see if I can reduce that loss of power state.

In addition, you assumed I was trying to discuss something unrelated.

It is obvious to me that getting even the most trivial details from you is going to be a concerted effort. I leave you with a quote from The Sharks: "I'm out."

cedar_door: This is just an exercise in engine control automation, nothing safety critical about it.

Just out of interest, how big, wingspan and weight etc, is this 'ultralight MODEL aircraft'

Robin2: If the Attiny does the job then it is the right thing. But the way you referred to it in your Orginal Post made me think you were just using it to save a few cents.

On the other hand, even if the Attiny can do the job it may be easier to develop an Arduino project on one of the more standard Arduino processors.

...R

what are the more standard processors these days? I've been using 328p's for everything for the last few years.

Just reading this thread - and disregarding the application and potential safety issues, I'm still trying to figure out what you're actually trying to do.

As I understand it, you have two internal combustion engines that are mechanically linked, an intentional weak link which often breaks apart due to them not being tuned well.

Now you're trying to find a way to keep them better tuned (same power/speed) to prevent that link from coming apart, by measuring the speed of them (but they're mechanically linked so that should be the same?), then communicating the measurements to another AVR that adjusts the respective throttles.

Correct?

cedar_door: I've been using 328p's for everything for the last few years.

Exactly what I was thinking of.

...R