CDI/Engine telemetry using 9X and FRSky telemetry...

[JakeStew]

Hello everyone! My first real post here, so introduction is in order.

I've been working with a CDI ignition project on RCU. The hardware works great, but needs some improvements in availability and documentation. I've written the software for the CDI. It currently runs on a PIC 12F683 or 12F1840.

I got involved in the project because I wasn't happy with the CDI systems that are currently available. All the CDI systems out there either aren't programmable or are way to heavy and expensive. None of them at any price did what I wanted to do anyways. Necessity is the mother of invention, so I joined the CDI project on RCU and whipped up some software for them.

The long and confusing project thread is here...
http://www.rcuniverse.com/forum/m_10662 ... ey_/tm.htm

My project page is here...
http://www.electrofunnel.com/CDI-2012/index.htm

I have a lot of features planned for the CDI, but one of the main goals I have is adding telemetry. I'd like to report RPM and engine temperature, and possibly some sort of remaining fuel calculation.

Sounds pretty simple, but there's probably a lot of work involved. I'm hoping the experts here can help me get started.

I need to work out protocol details and how to display the telemetry on the 9X. I ordered a FRSky telemetry system and have a 9X, but otherwise I'm starting without any real knowledge of any specifics.

I'm hoping some of the firmware coders here will be willing to take up that end of the project. I can help with some CDI hardware for testing and write the PIC side of the firmware however it needs to be, but I have no clue about the 9X side of the project.

The first thing I need to sort out is what sort of protocol to use. It would be nice to use a binary protocol, and it would be easiest if the 9X could calculate the RPM from the uS per revolution value, but however this works out easiest for everyone will be fine.

So if anyone has the time and would like to have RPM and temp. data on their gas engines, jump on board and lets make something cool!


-Jake

[Kilrah]

Cool!

For those who use the frsky system with the telemetry hub (that has an RPM input for an optical sensor), all that's needed is to hook a "2 pulses per rev" signal to that input - and all the rest is already done. So if you've got a spare pin that could output this, there would be nothing else needed. The frsky system also already has a fuel sensor, so no work to do on your part, they could just use the existing sensor. Same for temperature.

[JakeStew]

Thanks, that sounds like an easy way to go. But I only ordered just the DJT TX/RX module combo. I'm not really familiar with the different hardware options yet. My ideas on how to approach things are only from what features I have though of for the CDI.

I'd like to have RPM and engine temp. Right now RPM is the only telemetry currently working, but a temp sensor is a major feature on my list. The fuel idea is something I've just been toying with. I figure that the CDI would be able to have a pretty good idea of the fuel consumption based on the RPM, which is why I thought it might be nice. If the 9X is getting the RPM data it could also calculate fuel consumption.

The other thing I have to think of is alternate telemetry clients... I first got started because I'd like to use gas engines in my drone project. The autopilot I use has no idea about gas engines, and it seemed like a really good idea to add some engine telemetry so the autopilot can know if the engine is running, and how well it is running.

The whole serial telemetry is something I'm just starting to get going on. I've done simple serial RPM to a terminal window, but not much else yet. I'd like to have wired and bluetooth connectivity to the computer for testing and debugging, bluetooth connectivity to Android smart phones (since it just seems logical with bluetooth), telemetry via the FRSky to the 9X, and also to the autopilot. Working with OSD systems would also be nice for some people (I don't personally use one).

So I have a lot of potential telemetry clients to support if possible. Most of the users will probably want to use the telemetry for tuning up their engines, but I don't know how many us the 9X or have telemetry on it.

It seems like a pretty big task to make all these things work together as cheaply as possible with minimal hardware requirements. It would be easy enough to send out two pulses every rev., but I'd also like to explore what can be done with the serial telemetry since that opens up a lot of other options for new features and will be the most compatible with the other potential telemetry clients.

I saw another post about using a hall sensor for RPM readings instead of the FRSky optical one. If people are interested in that it should be easy enough to make the CDI timer board handle that, and it's about as cheap to make as anything can be made. Thanks for letting me know about that. I'll probably make that an option since it will be easy to do.


-Jake

[Kilrah]

A hall sensor can already be connected directly in place of the frsky optical sensor, no need for more.

Serial is more work, because as you've probably seen every manufacturer uses its own, different protocol, that most of the time aren't documented. So if you want to integrate with them, you'll have as many different protocols to implement and possibly reverse-engineer.
The 9x firmwares extensively support the FrSky protocol, simply because of the popularity of the frsky gear due to the low price, great features and reliability. Frsky is also nice enough to provide specs for their equipment and protocols, so it's very developer-friendly.
There is also some support for the ardupilot / MAVLINK system, but with no real feedback at this point.

As a starter, if you want to send down RPM info through frsky without a hub an have it understood by the current 9x firmwares, the best is to simply emulate hub frames according to that spec, and use the RPM, Temp, Fuel fields:
http://www.frsky-rc.com/uploadfile/2012 ... 905895.pdf

Here's the spec about connecting to the receiver (page 1): http://www.frsky-rc.com/uploadfile/2010 ... 837352.pdf

[JakeStew]

Awesome! That's exactly what I was looking for!

It looks like I can just use the sensor hub protocol and the 9X firmware can already handle the rest. This should make things pretty easy! Monitoring the CDI battery is also a feature I forgot to mention, but it looks like that will work out well also!

It will probably also be easier to work this into the autopilot by doing this.

[jhsa]

What's the max temperature your engine can reach?? I've been testing with a temperature sensor that will go in my extra .60.
it can read from 0ºC to a maximum of 150ºC with best accuracy until 125ºC.. It's the TMP37. just connect it to 5V and ground and the output pin directly to the analog port of the receiver.. then set the calibration value to 165 on the 9x's telemetry screen, et voilá.. temperature reading

[JakeStew]

I haven't done anything with the temp yet. I have a few temp sensors laying around, but will probably start looking for a good one.

Most people using the CDI right now are using them on conversion engines. Mostly small 2-stroke weed whipper engines. I've got a Honda GX-35 clone (4-stroke) and a Homelite 25cc (2-stroke) that I use for testing.

Once I get telemetry working well that will be a good reason to get the temp and other sensors working. Right now there's been no point for a lot of features, and I'm the only C programmer working on the project at the moment, so it's one step at a time.

Thanks for the info, I'll be sure to check that one out when I'm looking around for temp sensors.

[MikeB]

The FrSky hub supports two temperature sensors (100k thermisters).

Mike.

[Reacher10]

If a hall sensor can be plugged directly into the frsky hub then shouldn't I be able to use one mounted just like the one thats being used for the CDI ignition. However this will only be triggered by one magnet which would give me half of what the rpm's really are, ie: 3500 rpm's on my tx screen would be 7000 rpm at the engine. Is this correct? If so then if we have an option to select CDI ignition it could be programmed to give the correct rpm reading. Is this correct?
OK, now using a dedicated hall sensor all i need to do is hook the
wires to the hub just as, + to +, - to - and the signal wire to the third pin. Is this correct?

Now last, can the CDI hall sensor itself be used with a Y harness?

Any of the above would be great for getting rpm's on screen.

EDIT: I can test this with a 26cc I have sitting her.

Thanks
Rick

[Kilrah]

It would need allowing selection of "1 blade" in the RPM settings, which isn't the case at this point.
Whether you can use the CDI's sensor with a Y cable would depend on the CDI and its sensor, no way to know but to try.

[Reacher10]

Right, CDI selection would in fact be the same as 1 blade. Perhaps Mike could give us this option.

I don't have the proper connector for the hub but i can just solder to the back of the hub.

I see the pin out on the hub is vcc, rpm, ground. So rpm would correspond to the signal wire. I'll hook it up and spin the engine with the starter which gave me 190 rpm on my cdi tach so I should get a read out of 95 rpm...there abouts.

[Reacher10]

OK...it's looks like we have something here. It turns out I had to swap the pos. and neg. on the hal sensor. I get 396 rpm on the 5 blade setting. Now when I divide this in half I get 198 which is just about where it should be.

............Tx shows / divided by / equals

2 blade = 930 / 5 = 186

3 blade = 640 / 4 = 160

4 blade = 480 / 3 = 160

5 blade = 396 / 2 = 198

I'll have to double check the rpm reading with the CDI tachometer.

So am I wrong or are these nnumbers backwards...shouldn't the 2 blade selection be half of what the actual rpm is?

[MikeB]

As I understand it, the value from the hub is "pulses per second". I multiply this by 60 and divide by the number of blades giving:
2 blades *30
3 blades *20
4 blades *15
5 blades *12

Your figures above show:
2 blades 31 pulses
3 blades 32 pulses
4 blades 32 pulses
5 blades 33 pulses

Mike.

[Reacher10]

Mike I have to confess I didn't look that deep into it. I just saw where others reported that a hall effect sensor would work in place of the optical sensor. Thats what I came up with. I'm not sure how the pulses relate to what I show.

Can we work with this?

[Reacher10]

Here are another set of numbers I did this morning.

Blades....CDI RPM.....Tx RPM

2...............223..........1080

3...............218..........700

4...............223..........540

5...............214..........420

Thes numbers were not taken in a controlled test...just me holding the engine and putting a starter to it. I would spin the motor and read the Tx RPM and then plug in the CDI tach and spin it again. I can't get the numbers at the same time because for ever reason once I plug in the tach I don't get any reading on the Tx.

I was about to check my other engine, SPE 43cc, which would have reported both at once but the hall sensor fried when tried to have the hub and the CDI tack with the ignition on all hooked up....don't ask...ordered a new sensor and should have it Thursday. I can still use the sensor on the 26cc.

I ordered 2 sensors, one just for the telemetry.

[MikeB]

Those numbers indicate the hub is reporting 35 or 36 pulses per second. I'm wondering if the hub processor is getting confused as the RPM is low, 223 RPM is only 3.7 pulses per second, maybe the hub is using a hardware timer to measure the time between pulses, but the timer overflows a 16 bit counter so gives the wrong answer.

Mike.

[Reacher10]

OK...I'm back. I had to send my board up to brent so he could get my audio working again and he also gave it some more HP. I have the hall sensor mounted to the engine and the next good weather window we have I will see how the RPM's work via telemetry.

Stay tuned.

[Reacher10]

Well I have RPM telemetry using a hall sensor. After all the stuff about the number
of blades I set it to 2 blades and that was very close. However it does not give a
stable reading. The other blade counts were way out of range.

On my optical tach it idles at about 1900 to 2100 and on the screen
it shows between 1800 and 2300 there abouts and the numbers really jump around.

I just ran it in the back yard so let me get it out to the field for a good fly and see
what how it goes.

Mike do you have anything in your tool box that can be used to smooth it out? Perhaps
using a pot to average it out and dial it in to the real numbers?

[MikeB]

How many magnets do you have triggering the hall sensor?

Mike.

[Reacher10]

I have just one magnet. I just saw that you did some work on the RPM calculation. I'm still using r138
so I will upgrade to r154 and fire it up the next time we get some good weather.

As always...Thank You Mike.

[jhsa]

with one magnet the calculation should be set to 1 blade, right? do we have such setting? or am I missing asomething?

João

[Reacher10]

Yeah, Mike put in to 50 blades when I first started messing with this. I have no idea why 2 blade
works when as you say it logically should only be one blade. Perhaps it has something
to do with the hall sensor I have or the way I have it plugged in?

[MikeB]

If you can, it would be interesting to put a 'scope on the signal out from the hall sensor.

Mike.

[jhsa]

if you use only 1 magnet the sensor will be triggered 1 time on a complete rotation. If the radio is set to 2 blades prop, then it will be expecting 2 pulses from the sensor, hence 2 magnets. This was normally designed for optical sensors.

[MikeB]

I was wondering if the hall effect sensor was actually giving out two pulses close together.

Mike.

[Reacher10]

I really have no idea how I could scope the sensor. I have very very limited electronics knowledge and even less equipment. Whenever I start messing with things and wire it up I always short things out.

I had bought a GPS module...I think the 411 or something like that to try and get it to work with Frsky. Well I did manage to get it working on my desk and it was actually very cool seeing the data on my PC screen but man wouldn't you know it. Because of the monkey rig I made up to power it and get the signal to my computer....I eventually fried it.

In fact I fried a hall sensor also when I first started messing with this.

When the DHT module arrives next week and I put the latest FW in or if I know for sure I can move to the current FW revision and be safe backing it up I'll take another look at the RPM readings and see how it looks with your new RPM calculation. I could take some video and you could see what I see.

I'm sorry I can't be of more help but like I said my knowledge is limited however I will tell you this, it has increased 100 fold since I bought this radio Alas I am still a babe in the woods compared to the stuff that you guys figure out...I'm in awe!

[Reacher10]

Here is video of what my RPM's look on my Tx screen. I set it at 1 blade, 2, 7 and 8 in the video however I did try other bade counts. The numbers are all over the place.

I'm not sure if using a hall snesor will work.

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

[Reacher10]

OK, I remounted the hall sensor and the RPM reading is stable. The low RPM reading appears to be close to actual however the high RPM reading doesn't go high enough. I am using the 1 blade setting. I think there was too much of a gap between the sensor and the magnet which was causing the erratic readings initially.

I plan on flying it this weekend and give more concise results on actual RPM's compared to the telemetry RPM's.

Looking good Mike!

[Reacher10]

I have a good number of flights on the Cap232 and the RPM telemetry is rock solid! The numbers match my hand held optical tach.
I'm not sure why but initially the telemetry wouldn't go above 3k but it's working fine now. This is a very nice feature for my gas engines.

One thing that would be very helpful is a custom field to hold the max RPM value. It would be very helpful to know the true max RPM's in flight when the engine unloads as opposed to max RPM's when the plane is static on the ground.

Simply outstanding Mike! Thanks!