There are several problems, some of which are mentioned in other answers. I'll reiterate them for completeness's sake:
The Arduino's output is loaded with the mosfet's gate capacitance. That can be several nF. Given that Arduino's outputs switch in ~10ns, so you're creating large current spikes with that load. The path of those spikes is not controlled and pollutes the rest of your circuit.
The gate input is clamped to the LED's forward voltage. The mosfet might not be fully turned on.
The output pin's driver is likely driving its full output current into the LED. Since that current is very likely to share lots of circuitry with the analog reference signal, you're corrupting your ADC reference voltage.
The car battery can push hundreds of amperes through your circuit. With no fuse, you will burn your lab/house down.
The inductor will likely need a snubber for EMI minimization.
You have no slew rate control for mosfet turn-on/turn-off. You're likely switching the mosfet way too fast. You need to trade off some heat dissipation for improved electromagnetic compatibility.
The fast switching PWM current path needs to be kept as short as possible: you need to isolate the inductor-switch loop from the battery and the rest of the circuit.
There may be capacitive coupling between the inductor and the Hall sensor.
Below is an attempt at addressing all of the shortcomings.
Let's say that we want to keep the mosfet switching times roughly at 2% of the PWM period. The mosfet should switch in approximately 2.5us. The low-pass filter formed by the gate drive resistance and the gate capacitance should have a time constant of, say, half that value. Thus, assuming a 1nF gate capacitance, we need an equivalent 200 Ohm series resistor in the gate drive circuit.
Ensure that the fast-switching current loop, drawn in thick line, is kept as short as possible. The decoupling C1 needs to be a low-ESR electrolytic. The snubber C2/R3 can be designed following this procedure. The buffer U2 can be 74HC1G125 or similar. It needs to have its power supply decoupled with a 47nF capacitor, and have its output enabled (OE# input driven low). U2 needs to be close to M1. To ensure fastest turn-off, the D2/D3 is a pair of back-to-back 27V Zeners. F1 should be sized to accommodate the power consumption of L1. The GND of U2 needs to be tied to the star point at M1's drain. Ideally you'd also have ferrite beads between U2's VCC and the 3.3V supply rail, as well as between the star point at top of L1 and the output of the fuse. The FB1 is a ferrite bead - choose the largest impedance you can find that will handle 100mA.
simulate this circuit – Schematic created using CircuitLab
To minimize the Hall sensor's capacitive coupling to the inductor, there should be a non-magnetic, conductive shield around it. It won't hurt to make an explicit low-pass filter on the sensor's output, as well as decouple any high-frequency content with a ferrite bead FB2. Choose the largest impedance you can find that will handle 15mA.
simulate this circuit
I have added a representation of how the circuit might look on a breadboard. I've paid particular attention to minimizing the coil circuit's loop area. I've used 74HC14 inverters as a buffer, and I'm paralleling the outputs that drive the LED and the gate.
Due to 123D Circuits' limitations, I had to:
Represent the 24V battery and fuse by an AA battery holder and a resistor.
Represent the Hall sensor by a potentiometer.
Represent FB1 by a small inductor.
PART 1
1.) Your battery is shorted.
2.) The input to your Arduino supply doesn't have the battery across it.
3.) You should be switching the input of the LM317 and current-limiting its output using the voltage dropped across an output resistance to ground.
4.) You don't need Q1, Q2, or Q3
5.) 10.5 volts across 7 LEDs is 1.5 volts per LED, which won't work.
PART 2
Thanks for cleaning up your schematic.
A new problem which comes to mind is that even if the circuit itself wasn't flawed, I don't think the LM317 is quick enough to give you a faithful 7.1 microsecond pulse every 26.3 microseconds, which is what a 27% duty cycle signal will look like at 38kHz.
Not only that, your circuit isn't a current regulator it's more like a HMMM....
The trick to getting the LM317 to regulate current is to wire it like this:
where with the current desired through R1 (your LED array) and R2, the drop across R2 will equal 1.25 volts, which is what holds the output at whatever voltage it needs to be to push 100mA (in this case) through the load and the sense resistor.
The rub here is that with E3 needing to be at 1.25 volts and the LED array dropping 10.5 volts with 100mA through it, E2 needs to be at 10.5V + 1.25V = 11.75 volts.
Then,from TI's data sheet:
It becomes apparent that you need at least 3 volts of headroom for the LM317, so your supply voltage must be at least 14.75 volts.
With that in mind, and considering that the LM317 might not be able to switch at the rate you need, it seems to me that a much more sensible arrangement would be a vanilla LED pulser using a single MOSFET, where each of the 100 ohm resistors is the equivalent of a string of 7 IRLEDs in series, and the 20 ohm resistors are their current-limiting ballasts, like this:
Finally, here's the LTspice file you'll need to run the simulation of the pulser and play with the circuit if you want to.
PART 3
I can't help but think that at least part of your problem is the circuit layout, which could easily be causing the oscillation you seem to be experiencing. You should watch your lead dress and place the components on the board with at least some care.
Here's an example of
an old, nicely laid-out wire-wrapped prototype which gave us no trouble at all during testing. Notice that all of the components are securely anchored close to the board, and that the wire-wrapping is roughly equivalent to PCB traces.
Not as stable, but not bad.
Best Answer
Seems like you are trying to filter the digital value as stored on your microcontroller. I would implement a moving average on the value. It's easier than filtering the signal through an analog circuit..
Here is someone who has implemented a moving average in C. Just remember to keep length of the average short enough.