antus wrote:That is cool. I can confirm you can do interupt driven IO on the Pi, but some implementations poll. I have experimented with both monitoring some PIR sensors in my shed, and found they both work but a direct hookup to long wires carrying logic level signals is very noisy. That'd be best handled in hardware. In my case on every trigger I took 3 more samples and if all 4 were the same I called it a real trigger. That really loaded up the CPU though and the pi's power consumption doubled compared to polling, because of all the false triggering. So hardware filtering is your friend.
Good to know. I've yet to use a Pi for anything outside of a H264 decoder (I use it as a "tv" to stream my HTPC's screen to the kitchen for my wife). I have not played with low level hardware stuff in a linux OS yet, but I imagine it wont' be too bad.
As a note to you, when feeding long wires, if you can feed it to a differential driver instead of a single ended signal, you'll greatly reduce your noise. RS-485 is more or less differential RS-232 and is used to operate ridiculously long cables.
I found a library called Pigpio, which seems to have very heavily optimized functions for the Pi to reduce overhead significantly. I'll be looking into that as well. My thought for the wheel speed is that i'll set an interrupt for each edge change. Check a timer, measure the time between pulses, and then I can calculate the RPM. I'll likely feed the time value into a circular buffer and average it out to smooth the readings a bit. My calculations show that 2 kHz is the upper limit out of a wheel hub if the car is doing ~160 mph. I would like to think a 4x 1.5 Ghz CPU can handle that...
Another update regarding the schematics. I've decided to completely redo my analog input stage. Mainly because 1) The signals share a low reference, I should use that instead of powered ground, 2) Ability to reject some common mode noise on the signal lines if they're ran close to each other, 3) I need to implement a low pass filter for the ADC that will come afterwards.
I think I'm done with the schematics, as far as I can tell, unless I screwed up the torque requested and delivered signals. I attached the PDF of the HAT.
I only use the differential amplifier stage on the sensors. I'm still not sure what the waveforms on the torque requested and delivered signals are. I'm hoping to get my vette running here within the next few days, and I'll get a datalogger on it to see. I suspect it's either an analog voltage, or a PWM'd signal.
With that being said, I redesigned it into 3 easy to understand stages. A buffer stage since I don't know what the source impedance of the sensors are, so I buffer with high impedance unity gain op amps to prevent screwing with the sensors. The buffered signal is fed into a differential amplifier configuration with unity gain, which will do (Vsignal - Vlow_reference) as the output. This output is then fed into the last stage which is a second order low pass filter with a -3db point set around 2kHz. Don't ask me why I chose 2kHz. I figured it would attenuate most higher frequency noise. I need to actually look at the sensor output to get an idea of if this can be dropped. I also have a DNP'd resistor to skip the low pass filter if I want to feed the output from 2nd stage to the ADC directly.
The bad: 5 op amp ICs are needed to pull this off... each one having 4 op amps. That's 20 op amps to condition 8 inputs. I'm tried to combine stage 2 and 3, but couldn't get good CMRR with filtering. Then I think it makes sense to keep it separate so I can disable or adjust the filter if I need to without giving up the differential amplifier.
I also ran some simulations to make sure that it worked as I expect (at least with ideal components).
Here you can see the red waveform is the input waveform with 600 mV of AC noise getting coupled onto the sensor wires. Green is the output, and you can see the differential amplifier is doing its job quite well to produce a beautiful noise-free output waveform. I tested DC and some switching waveforms. DC isn't exciting to look at. The input wiggles, the output is a flat line like it's supposed to be.
Here's the frequency response of the entire 3 stage network. I used a 2nd order low pass to get a better cut off. This will likely require tweaking.
I think I'll grab a raspberry pi and stick it under this seat with the OBX and datalog with this. I can build a cape for the analog inputs for it. Then bam, cheap datalogger that you can ssh or VNC into 
