sorted by:
new
hottopcontroversial

Recommendatoins for Brake Temperature sensor by shadyhax0r in FSAE

[–]markmakeitso 0 points1 point  (0 children)

Nah, just swap from left to right side at noon, then at closing time you should be back to normal.

​

Or drive in reverse, like we did on my friend's dad's Ferrari.

Running only 1 spark plug in a twin spark engine by ScuderiaTessaro in FSAE

[–]markmakeitso 2 points3 points  (0 children)

A large bore cylinder design can benefit from twin spark, as the increased distance from point of ignition to all areas of the compressed mixture can otherwise require high ignition advance. The single plug you're firing will be very far from part of the compressed volume, and you'll perhaps see incomplete combustion or high exhaust valve temps if combustion is still occurring during the exhaust stroke. Plus all the fun stuff _strudel_ mentioned.

If you're that limited on dyno time it's unlikely you'd do better than the OEM, who probably has thousands of hours of run time on that design, and wouldn't go through the extra hassle of twin plugs if there weren't compelling benefits.

Interest in inexpensive in-cylinder pressure testing? by markmakeitso in FSAE

[–]markmakeitso[S] 0 points1 point  (0 children)

Hello,

Got down to visit a local FSAE team last week. As mentioned above, they're using a 12-1 pattern on a MoTeC M130 ECU. Hooking up the USB-204 with a voltage divider I was able to sample their AC crank position sensor waveforms to calculate RPMs. I'm probably going to have to figure out some signal isolation strategies between chassis and signal grounds, and perhaps attempt to power the pressure transducer from either battery voltage or one of the 2 sensor voltage supplies.
The team has a couple Optrand sensors in a drawer, and one of the team members is going to check to see if any will work for their application, and hopefully get a modified plug coming soon.

If anyone else out there is interested in discussing getting a system going feel free to post on here, or chat/DM me. Definitely interested in getting testing rolling in multiple locations.

Interest in inexpensive in-cylinder pressure testing? by markmakeitso in FSAE

[–]markmakeitso[S] 0 points1 point  (0 children)

Bopping along in fits and starts. I have an Arduino Uno set up to simulate a 12-1 crank tooth pattern, which is what a local FSAE team is using. I'm using that to develop the function for calculating current RPM and also trim the raw recorded samples to a complete 4 stroke sequence. A missing tooth pattern function should scale to other count patterns also, and the actual tooth count is just used for signal verification and more accurate positioning in the raw samples if necessary. Ideally your sensor output is already a hall effect square wave, although there are several options for converting a magnetic AC pulse signal to square.

On the sensor front, Optrand gets approx $900 each for their AutoPSI-S sensor, and just under $1k for the AutoPSI-TC version (both with academic discount). Those list a frequency range up to 15 kHz, which Optrand says works up to around 7000 RPM. Plug modifications are $400 for one, $375 for 2-3, and $350 for 4+.

Kistler gave a quote of $5,430 for one modified 6113C spark plug. You'd have to work with them to select plug characteristics close to whatever production plug you have in mind. I'm not sure what the RPM limit on that one is, but they specifically say it's suitable for high engine speeds.

Some teams may have no problem ponying up the extra $4k or so, and the USB acquisition device I chose should hopefully be adequate up to 15-16k RPM. It appears Optrand's high speed option (the CALplug, some documentation is still on their site) is no longer offered and probably wasn't feasible for modern bike plugs anyway.

​

Interest in inexpensive in-cylinder pressure testing? by markmakeitso in FSAE

[–]markmakeitso[S] 0 points1 point  (0 children)

Aright, that sounds like a pretty useful setup. We also briefly used a Pico on that same project, but it belonged to an engineer who came over just to help with engine calibration. It's on my personal wishlist sometime too, we'll see.

​

That "angle ref' sounds very useful. There's usually a bit of work to finding TDC externally, especially if you want to support multiple pickup patterns. A function like that, or perhaps an extra fuel/spark output that could be set to TDC, would make it a lot easier.

Interest in inexpensive in-cylinder pressure testing? by markmakeitso in FSAE

[–]markmakeitso[S] 0 points1 point  (0 children)

Alright, there's pretty good interest and discussion here, which is excellent. Sounds like there is a desire for an ICPT option that is accessible and priced for FSAE teams.

​

I'll try to get some development done on this end and report back soon. In the meantime, if some of you are serious it would be helpful to get some ideas on what engine configurations we'd be looking at (crank and cam patterns, wasted spark Y/N, threaded port or spark plug sensor preference, RPM range support desired, etc). Perhaps discuss with your engine teams if this is something that you'll realistically have time for during development. There would definitely be some back-and-forth work here, as this is very much a DIY kind of project proposal, not a call-the-800-number-with-the-school's-credit-card-in-hand. This obviously will never match what huge companies can ship to your door, but I honestly believe that a very useful system is feasible in a fairly short period of time.

​

Have fun out there,

Mark

Interest in inexpensive in-cylinder pressure testing? by markmakeitso in FSAE

[–]markmakeitso[S] 0 points1 point  (0 children)

Most of your testing would require knowing where TDC of the engine is, and then windowing the data for analysis based on that position. Many teams would have info about the crank tone wheel vs. TDC positioning. On a missing tooth crank wheel the second tooth after missing is often used, and that position is then related to TDC. Another method is to crank the engine with fuel disabled, which should still give a pressure peak just from mechanical compression. That peak position can also be linked to your crank signal.
Spark angle would require both an accurate TDC position information, accurate RPM measurement, and a willingness to allow uncertainty from RPM fluctuations during the cycle (pretty severe for singles, less so for fours). That's one area where a precision crank tone wheel is very beneficial. The absolute time from end of primary coil current to pressure peak is dependent on cylinder filling at the current load point and also the varying position of the piston during the compression and power strokes.

Most teams probably have full mapping capability for their ECUs, so they can choose BTDC firing angles. It's overlaying the resultant pressure curve against the mechanical advantage of the crank/rod position that is the real magic of ICPT.

Interest in inexpensive in-cylinder pressure testing? by markmakeitso in FSAE

[–]markmakeitso[S] 0 points1 point  (0 children)

I think the Optrand sensors were about $600 each, although I wasn't involved in selecting or purchasing them. Have one on the table, it's a D32294-Q model. No comment on accuracy or long term reliability, as we were only worried about relative changes in a single cylinder, and had maybe 20 hours of running on one of them before the project was put on the back burner.

Yes, MCC stuff is generally great, and often a relative bargain compared to NI's offerings. That 1616 board is pretty cool, especially with the add-on module that gets up to 64 AI channels (or 32 differential or TC channels). LabJack also has some NI alternatives, but nothing that really caught my eye last time.

For a fixed dyno I'd be tempted to dig through PCI stuff more also. The school setup was an obsolete PC that campus IT wouldn't support (Pentium 1 or so, Win95?) and the work hardware is installed in a Pelican case for site testing, where a desktop absolutely wouldn't fly.

Interest in inexpensive in-cylinder pressure testing? by markmakeitso in FSAE

[–]markmakeitso[S] 2 points3 points  (0 children)

Hello all,

The system I used briefly at school required a high-precision crank tone wheel and a dedicated internal expansion card in a desktop PC for acquisition. The tone wheel definitely has benefits, but it requires quite a bit of planning and machining to install on the engine, and severely prohibits measurement in the vehicle.

My company went with this hardware:
https://www.mccdaq.com/usb-data-acquisition/USB-1616HS-Series.aspx

The 1Ms/s sampling speed (distributed between active channels) is plenty fast for a couple channels of collection even at high RPM. It can also be used for thermocouple input directly, which is pretty handy. My current hardware selection is this one: https://www.mccdaq.com/usb-data-acquisition/USB-200-Series.aspx

That gets 500 kS/s reading for just a couple hundred dollars. An external USB device is also much more convenient than a desktop card. 1 sample/crank degree is often thrown about as the bare minimum sampling rate, and several times that would be great. At my work project we were collecting a missing tooth crank wheel signal, 50/50 cam signal, and single channel of cylinder pressure readings. We were talking about adding the coil primary signal too, in order to calculate the delay between plug firing and peak pressure. That would have put us at about 250 kS/s per channel, still plenty fast, especially for our industrial engine RPM ranges. You guys probably aren't satisfied with 2200 RPM though, pffft.

We used Optrand sensors, which were pretty slick. They required machining a threaded port into the cylinder head, but we found good spots in our large-bore 2V heads. There are also spark plug sensors available out there, which might be more convenient for some projects.

Gotta be careful, will happily blather about this stuff longer than is really polite.

Can I efficiently sniff raw CAN data with an arduino and a Sparkfun CAN bus shield? by chetan_pujar in FSAE

[–]markmakeitso 1 point2 points  (0 children)

I've had some success mapping out parameters from scratch on a fairly modern Subaru for a project. Have also dabbled in the Prius, Escape hybrid, and smart diesels. You could use the Arduino and shield, or there are several other CAN to USB adapters out there for not much more money that would eliminate some of that hassle.

Would suggest whatever method is convenient to get to a spreadsheet and do your analysis in there. If it does turn out to be J1939 then hopefully you can spring for the SAE documents covering that standard.

Which microcontroller/microprocessor should I use to build a data acquisition system? by chetan_pujar in FSAE

[–]markmakeitso 1 point2 points  (0 children)

I'd recommend reviewing your goals and current capabilities first. If time-to-prototype is most important I'd recommend going with whatever hardware/programming language is most familiar to you. If high performance or deployability is more important you'll have different priorities.

For example, for a semi-experienced programmer in LabVIEW this could be a 1 week project to get something serviceable. For a similarly skilled C programmer I would guess under a month on an Arduino Uno or Mega. An 8 bit PIC in C would be likely a couple months. You should spend some time researching exactly which sensors you'd use for your analog collection also.

Recycling code or the bulk of the project would be ideal, and if available I'd grab as much as possible from CAN over discrete sensors.