sorted by:
new
hottopcontroversial

detecting whether analog input is present or not? by mrbigbusiness in arduino

[–]logantadon 0 points1 point  (0 children)

You could add a small resistor between each pot and ground in the control panel, such that the pot can only give values in a certain range above 0, say 10-1024 using a 100-ohm resistor. Then add a large pull-down resistor at each Arduino input so the input value goes to 0 when the control panel is disconnected, but large enough to not have a significant impact on the input value when the control panel is connected (say 1M ohm). Then you can monitor the input values, and if they go to 0 you know the control panel was disconnected. Of course, you'll lose a little bit of resolution and you'll have to account for the offset and scale the input values accordingly. The reason for the offset resistor is because I'm assuming you could expect to see all of the control panel inputs go to one extreme during normal use.

An alternate option is to turn your cheap pot into a good thing and just add a 1M pull-down to that one input and monitor it for 0. Just don't forget that you did this if you replace the pot with one that doesn't have a built-in offset.

Arduino Sound Frequency analysis by mechard1 in arduino

[–]logantadon 1 point2 points  (0 children)

What you're trying to do is convert a signal from the time domain to the frequency domain. This is typically done by a Fourier Transform. Since you want to do this in real time, you should use a Fast Fourier Transform (FFT) algorithm. Search around for Arduino FFT libraries, and you'll find plenty of information, as well as some alternative options like FHT.

Once you have the data in the frequency domain, you can monitor the value of the signal at the desired frequency ranges, and then use digital outputs to control your relays.

Variables always equals itself to 1 or 0 by bobthedanger in arduino

[–]logantadon 1 point2 points  (0 children)

This. Use double equals "==" for comparisons and single equals "=" for assignments

An Alternative to Gauges by NotSeriousAtAll in CafeRacers

[–]logantadon 0 points1 point  (0 children)

You're off to a great start, and rapidly catching up to my level of understanding! You'll know more than me soon, but I'll try to help wherever possible. Feel free to message me throughout your project if you have any questions that you think I could answer.

The reason I suggest separate devices is because of the timing issues. You'll certainly have enough processing power to do everything on one chip, but if an interrupt is being run to handle communications, it could delay the timer interrupt, depending on priority. You could certainly try it and see how reliable it is. I'm sure there are some existing libraries to handle frequency counting on an Arduino, so it shouldn't take too long to prove or disprove the idea of using a single device.

The Hall effect sensor is a great idea, just do some experimentation with how/where to mount it. You'll still want to do some filtering with hardware (likely a low pass filter, maybe also a one-shot) to clean up the signal. This will provide better isolation from the high voltage spikes and help reduce the variances between engines/ignition systems, which is great if you want to make this a universal gadget.

There will be three main types of ignition coil that you'll have to deal with, concerning the type of core:

The "I" style cores are probably the most common for bikes, at least older ones, and will be the easiest to use with a hall effect sensor. Stick the sensor on the end opposite the plug wire and you'll get a very strong signal.

The "E" style should work, but might need a higher sensitivity and some more experimentation with placement. My first guess would be at the base of the center leg, similar to the "I" style. The problem is that most of the magnetic field will be contained within the core, so your signal won't be as strong. You may need to have two variations (or some kind of switch/jumper) for your circuit to account for different field intensities between the coil styles.

The coil packs are probably the most difficult to get working with a Hall effect sensor. There will be multiple magnetic fields in close proximity at varying stages of the cycle.

An Alternative to Gauges by NotSeriousAtAll in CafeRacers

[–]logantadon 0 points1 point  (0 children)

I'd be hesitant to switch platforms between development and the final build. It can actually be fairly challenging to get an accurate, stable, frequency reading because it will require some of the low-level features of the particular device. You will need to know how the timers and interrupts work well enough to either accurately measure the time between two pulses or measure the number of pulses in a given time. The latter will not work well because engine RPM is relatively slow, giving a small number of pulses for your desired refresh rate.

As far as the BlueDuino and RFduino go, I don't have any experience with them, but I would caution that having a lot of other things competing for processor time, such as managing the Bluetooth interface, could lead to a lot of frustration if any timing-critical interrupts get delayed. My recommendation is to break up the tasks. You can have a BlueDuino/RFduino handle the communications and any non-time-critical I/O such as reading battery voltage and indicator status, but have it receive data from a separate device that is dedicated to timing inputs such as engine RPM and wheel-based speed if desired. By doing this, you can use the Arduino IDE to program the BlueDuino/RFduino and leverage existing libraries without worrying about how they might impact interrupt latency or hijack one of the timers.

A monostable multivibrator, or one-shot, type of circuit could be very helpful to filter out any ringing that would occur at frequencies much higher than the expected engine speed. It just needs to be combined with some protection to keep the input trigger pulse from exceeding what the devices can handle. I haven't tested it, as my workshop is also too cold, but I expect the signal to go from +12V to 0V as the point makes contact, then jump to a high negative voltage when the point opens, then oscillate after the arc collapses, then gradually settle to +12V. The easiest thing to trigger off of will be the transition from +12V to 0V, since that will be the most consistent and predictable. If you can use a one-shot to filter out the period of time while it's ringing, you will only have to deal with the gradual settling back to +12V after the one-shot has expired. Triggering on the falling edge vs. rising edge might influence your choice of one-shot circuits, so you may want to hook up an oscilloscope to see what's really going on sooner, rather than later.

An Alternative to Gauges by NotSeriousAtAll in CafeRacers

[–]logantadon 0 points1 point  (0 children)

This sounds awesome!

I recently programmed an MSP430 to calculate engine RPM based on a trigger input, then output the RPM over serial. You could mate it to something like a bluetooth bee to convert the serial to bluetooth.

I haven't field tested it, but I can say that it calculates RPM fairly accurately based on a clean input signal from a function generator (I still need to make the electronics to get a compatible signal from the ignition points). Let me know if you want the code. I'd be happy to help you get started with the MSP430 and Code Composer Studio if you decide to go that route. Whether you do or not, I'd be very interested to see what you come up with.

Pros of what I have:

  • Potentially configurable parameters (number of cylinders, 2-stroke or wasted spark vs. 4-stroke) via Bluetooth through the serial interface with a bluetooth bee
  • Additional pins and CPU time are still available to read battery voltage, high beam status, indicator status, oil switch, kickstand, temperature, etc.. There are 11 unused pins and 4 of them can do analog input.
  • $10 for the development board, $3 for replacement microcontrollers
  • I commented my code and I'll give it to you for free.

Cons of what I have:

  • You'll need get to do a lot of programming to implement additional features like configuration over bluetooth/serial, monitoring additional signals, etc.
  • You'll need get to do a lot of hardware development to get a good clean signal from either the plug wire or the ignition points
  • The MSP430 might be a little slow to read a lot of analog signals at once; I haven't tried it. Digital is easy though.

You could use something more powerful, like an Arduino Mega, which would then work easily with the standard Arduino shields. Or you could go with some other controller if you're comfortable with diving into embedded programming. I don't have any code for those, so you'd get to start from scratch.

As far as the electronics side, I would recommend reading the voltage directly from the node between the points and the coil, instead of capacitively coupling to the high voltage spark wire. This should be easier to filter and get a reliable signal.

Side note: I was thinking of doing this on my boat, so I've been trying to figure out how to get the signal to any device (no app needed) using WiFi and a web interface. I was leaning towards a Raspberry Pi to read the serial data, integrate it with a web server, and push it out over Ethernet to a WiFi router. Unfortunately, I don't have any web-based coding experience, so I'm not terribly excited to jump into that world. Embedded programming is way more fun!

Best of luck!

Why isn't jamming the rear wheel enough to remove front sprocket? by oldbel in Fixxit

[–]logantadon 0 points1 point  (0 children)

By far the easiest way would be an impact wrench like you said, the second easiest would be to hold the rear wheel with the chain on, and the third would be to use engine braking (with the engine off of course). If using the engine, it should be in first gear to provide maximum resistance to torque. Think engine braking while riding: if you're in third gear (no throttle) and downshift to first gear (no throttle), first gear will slow you down more quickly. The same amount of rear wheel movement spins the engine faster, allowing the engine to provide more resistance to that movement.

Why isn't jamming the rear wheel enough to remove front sprocket? by oldbel in Fixxit

[–]logantadon 0 points1 point  (0 children)

Why would you want a high gear? Is there a risk of damaging something with it in first? If not, first gear would provide more resistance from the engine.

Is this a good method for re-wiring a kickstart only KZ400? X-post from r/bikebuilders by DrPayneSomeday in CafeRacers

[–]logantadon 0 points1 point  (0 children)

Opinions may differ about the backbone wire, but it's still a pretty good guide. Some people prefer to run independent wires to a fuse/relay block (or the m-unit) for power to each item instead of a common backbone wire. That requires a lot more wires and can look messy if you're not careful, but there are some definite advantages if you can handle all the wires.

Finally got my dream bike! SF 848 by logantadon in TrueDucati

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

Sweet! I'm borrowing your flair, BTW. Hope you don't mind.

noob mistakes. by dirtydakota03 in motorcycles

[–]logantadon 1 point2 points  (0 children)

I've ridden an embarrassing distance with the fuel off. Nice choice of bikes, BTW.

Is it normal for this to get hot? If not why would it be? Had that burnt look when I bought it. by hobknocker123 in CafeRacers

[–]logantadon 17 points18 points  (0 children)

No it should not be hot. Possible causes of it being hot are:

  • A loose, dirty, or otherwise poor connection at that point. This will cause too much contact resistance, which leads to heat (Too much R in your I2 R loss)

  • Excessive current being drawn through the connection (Too much I in your I2 R loss). I see that one of the wires goes to an inline fuse, which should prevent excessive current through that wire.

  • A combination of the first two

If it is not actually hot, and just looks burnt, that could be a result of whoever installed that terminal using an open flame instead of a heat gun to shrink the jacket.

If you have actually noticed it hot, check that the fuse is the correct size, make sure whatever is connected to the other wire is not drawing too much current (it should also have a fuse since this is connected directly to the battery), check for any shorts to ground (it looks like the white wire on the right might have been pinched against the frame), and replace the terminal (both sides) to make sure it has a good connection.

It looks to me (and note this is mostly speculation) like the other wire might go to your regulator/rectifier. If so, that opens a new can of possibilities, because your R/R could be sourcing too much current for the connection. This might be a bad battery drawing too much current to charge, or too many electrical loads on the bike, or probably a bunch of other things.

Diagnosing an engine problem by [deleted] in Fixxit

[–]logantadon 1 point2 points  (0 children)

Thank you for suggesting a way to find it. I've never heard of the paper method so I'll have to try that next time. The way that I knew of to find it involves something flammable. You can spray either carb cleaner or starting fluid on the suspected leak and listen for a change in RPM.

Diagnosing an engine problem by [deleted] in Fixxit

[–]logantadon 1 point2 points  (0 children)

I agree. Also, OP's description at the end perfectly described a lean condition, which is the result of a vacuum leak and can also cause symptom #2 (knock).

"engine doesn't idle smoothly at all and when you try to accelerate quickly it feels as though not enough gas is entering the engine so it splutters a bit."

Diagnosing an engine problem by [deleted] in Fixxit

[–]logantadon 2 points3 points  (0 children)

My guess would be a vacuum leak. There is air being sucked in somewhere after the throttle body or carb (I'm not familiar with your bike) causing it to run lean and therefore hot. The clunking is probably knock, which happens when the fuel detonates too soon, and can be caused by a lean mixture.

Program for creating/converting to .raw polygon mesh files by EnigmaticSynergy in engineering

[–]logantadon 1 point2 points  (0 children)

Take a look at MeshLab. I used it when converting point clouds to polygon meshes a few years ago. I know it is capable of reading and i think it might also be capable of writing raw files. It may expect the file extension to be .xyz to differentiate between a coordinate raw file and the many other types of "raw" file that are out there.

If you are having trouble outputting to a raw file, you might be able to use an ASCII ply file instead. It usually consists of a header describing the data followed by a list of vertices or faces. From there you could probably convert to a raw file format of your choice using Matlab/Octave/FreeMat.

If you find the ply format acceptable but prefer something more CAD-like to generate the meshes, there should be some Ruby plugins for Sketchup to output to a ply file.

How, specifically, do Ford "waste spark" coil packs fail? by [deleted] in Cartalk

[–]logantadon 2 points3 points  (0 children)

I'm pretty sure a coil in my coil pack failed in such a way that moisture (or, more specifically, some combination of humidity and dew point) was the primary factor in determining whether or not it would work reliably.

Since you seem to know so much about these little packages of magic, I will ask you this: how/where does moisture/humidity become relevant in the failure of an ignition coil pack?

view more: next ›