Carduino becomes JeeCar « Jee Labs Talk

Jee Labs Talk » Uncategorized

Carduino becomes JeeCar

(21 posts) (4 voices)

Tags:

No tags yet.

radiotrib

Well I was toying with the idea of building an in-cat telematics system for the Kever hotrod I'm building for my grandson, and I discovered Arduino ... It looked ideal, and then, somewhere up the learning curve I came across JeeXXX ... liks nodes plugs .. everything I needed for a whole host of sleepless nights tinkering ..
So here I am. 2 JeeNodes built. Both tested and talking to a JeeLink, and a few plugs to play with. I have to admit, my C is really rusty (like 20 years of rust) and I don't relish the idea of struggling through all the ATMega supporting documentation, but I guess I'll get around to it.
Right now, my main task is to create a test harness to exercise any software I write. Initially, a big breadboard of potentiometers, switched and small motors will have to suffice, but once I get some tangible results I'll be mounting an old (and surplus to requirements) 1200 Kever engine on an engine building stand and wiring that.
Target inputs (Telemetry) includes: -- RPM -- Spark Timing -- Oil Temperature 2 (into and out of the cooler) -- Cylinder Head Temperature -- Oil Pressure 2 (into and out of the pump) -- Inlet Manifold Vacuum (and balance) -- Lambda Sensor (later) -- Gear Indicator -- others as I think of them
Outputs ???? Eventually I would really like to build the whole thing into a simple Engine Management System with Electronic ignition control and fly-by-wire throttle. As a side-project I'm also considering touch-panel controlled electrical circuits (lights, wipers, etc.).
Where am I right now ??? - Playing with the RPM/Timing issue. I've built the detector circuit (without the sensors) and tried some code ideas, but I'm not satisfied yet.
Once I get rolling I guess I'll stat blogging it.
Kevin

Posted 29/04/2010 14:38:33
twinkel

Nice, I am just in the same process as you. Rusty experience, starting to play again after so many years. I am also tinkering with the idea to monitor my car's inner working, just because I can ...
On top of your wish list I have: Measure injection pulsewidth, idle & full-load measurement, battery voltage and on top of that: a nunchuck or other gravity sensor to check the suspension over time.
I guess I will be struggling to combine ignition timing and injection timing with RFM12 interrupts. It's been a while since I made such combined ISR's, and that was in the 6800 / 6502 times. Funny to see that the systems I used to build can now all be in 1 chip.

Posted 29/04/2010 15:34:29
radiotrib

Heh Heh ... A 1973 beetle doesn't have injector timing :) ... but there are quite a few more parameters I (we) want to monitor once the concept is flying. As for combining time critical things like ignition and injection timing and injection dwell. I'm certainly going to throw a few JeeNodes around the car. After all - if I can build a rev-counter and timing display for less than 20 Euros, I already saved enough $$$ to have a JeeNode for every function bar the coffeemaker.
It's odd to do this because in parallel with the sensor system I'm writing a front end in Javascript and a server-side in PHP so I keep jumping from bit-fking to DOM-based event-driven UI code ...
It results in the mental equivalent of vertigo .....

Posted 29/04/2010 18:16:11
jcw

Maybe this project is useful in this context:

Posted 01/05/2010 15:15:02
radiotrib

Hey thanks J-C .. I'll keep a track on that thread to see how things progress ...
right now I'm struggling with trying to understand how to set up pin-change interrupt handling on a JeeNode and reading the ATMega documentation (man that's dense stuff!!) ... and trying to find documentation on whether and how I can use the IRQ line that's present on each of the 4 ports ... Is it an interrupt line? Is it implemented in Ports? can I attach an ISR to it in my own code?

Posted 01/05/2010 19:58:15
jcw

It's connected to PD3 (Arduino digital 3), a.k.a. INT1 on the ATmega. You can set it up as interrupt #1, see - see also how attachInterrupt() is called in RF12.c for an example.
Pin change interrupts are independent of this, any pin can be set up as such. No support (nor interference) from the Ports library.

Posted 01/05/2010 22:05:28
radiotrib

Ahaaa .. so the 4 IRQ pins are all using INT1 and Ports then would resolve which port was interrupting ... So .. onward and upward :)

Posted 02/05/2010 06:26:37
radiotrib

And finally I understand ... Not only are the ports of a JeeNode mapped to Arduino logical pins, but the Arduino pins are a re-mapping of the original ATMega pins too ...
So now I realise my mistake in imagining anything could be simple ...
PCINT20 == Arduino pin 4 == Jeenode Port 1 digital pin ...
and now the pin change interrupt is actually interrupting :)
Onwards and upwards :)

Posted 06/05/2010 09:31:59
jcw

Any suggestions what I could change in -ports/> to clarify further? The "AVR port" vs "JeeNode port" and the pin numbering are two issues which can probably really confuse newcomers.

Posted 06/05/2010 09:42:04
radiotrib

AAAAAAARGH !!! ... I completely missed that ... but there again, I probably still wouldn't have been able to make sense of it until I'd gone on my round trip of discovery and re-re-re-read the ATMega data sheet chapter on interrupts ... In fact, I recall reading it as part of my discoveries, but by the time the interrupt-handling bot made sense I'd forgotten about it again.
I don't really know if it's relevant, but one thing that beginner/intermediate coders might find useful is a mugs guide to Pin Change Interrupt handling. Maybe I'm just dim, or too much of a novice still, but the code for setting up the PCI registers is not only arcane, but uses pre-defined constants which are buried deep inside the lower-level header files. For that, it may be handy to cross-relate the pin map to the PCINTxx value somewhere. (I worked backwards from nowhere, eventually got it right, and then today I discovered this - http://www.arduino.cc/en/Hacking/PinMapping168 and you told me where to find the JeeNode part).
In a way I'm glad I searched and found because it improved my understanding, but I wish I'd remembered where to find the JeeNode port mapping ... I do feel a fool now :)

Posted 06/05/2010 10:47:22
jcw

Don't. There's both too little and too much info on the JeeLabs sites. Can't expect everyone to read everything that has ever been written down (especially the daily weblog).

Posted 06/05/2010 11:49:52
radiotrib

Finally got back to some micro work after bashing metal again for a few weeks and at last the rev-counter/spark timing detector is running fairly smoothly up to around 10000 RPM ... Unfortunately there seems to be a small glitch though. At regular, but random moments between 10 and 20 observations, it tends to report an odd value ... seeming to add around 30% to the actual RPM figure. I can't explain it ... The readings are consistent for a while and then ... pop .. up comes one, two or even occasionally three duff ones.
Timing over-run isn't a possibility because I'm combining the rev-counter pulse and the spark start pulst into one waveform ... rising for a spark, dropping for TDC/2 ... and the detector does a great job until it throws a wobbly .. then back to accurate again.
I'm at a loss, unless the timing of the pulse generator is glitchy, but that's unlikely because I'm onlt running a simple long delay->ON->short delay->OFF loop on another Jeenode ... I guess I'll just have to get my spare engine cranked up and start sticking detectors on it sooner than I thought :)
I'm also going to have to get into the wild and whacky world of i2c I think ... direct serial or RF12 comms from the detector node is out of the question at 10000RPM and a 30 degree spark advance ... there just isn't time to send and get back to counting again. Right now I only send every fifth observation to the collector node via RF12, but that has to improve ... so I think I'll add a tandem node to gather the data via i2c from the detector node, and use it to buffer and send a smoothed, rolling average at the slower rate for the indicator node to interpret and display. The indicator node can do a simple inter-observation extrapolation at its leisure ...
slowly-slowly ... but onwards and upwards :)

Posted 02/06/2010 09:40:33
jcw

Hardware serial will be able to sustain a lot more throughput than the default bit-banged I2C done by the PortI2C class. Or you could use hardware I2C through the Arduino "Wire" library on pins A5 and A6 (on the JeeNode's PWR/SER/I2C header).
FWIW, 10,000 RPM is only 166 values per second, i.e. some 300+ bytes probably. They could be pushed through the RFM12B if batched up a bit, but only by ignoring the 1% rule, if you're on 868 Mhz. The RF12 driver should be able to handle that quite easily, since it does most of its work using interrupts, i.e. in the background.

Posted 02/06/2010 12:24:58
radiotrib

Yep .. I did all the calculations, but still I cant report every cycle as I wanted to do. The major issue is that spark advance is never > 30 degrees, and that comes down to less than 500 usecs between the spark pulse and the TDC detection ... so often I miss one or the other if I'm transmitting ... I hoped that i2c would hold the key, but if not I will look at the timings again and see what I'm missing ...
I may look at separating the pulses into two individual interrupts, but that introduces potential errors in relating one pulse to the wrong 'next' one ... Right now I use the spark pulse to set a flip-flop (build from a 555) and the TDC puls to reset it .. the result is a sort of variable frequency/variable pulse width PWM waveform that I can test using a single pin change interrupt service routine. In fact, I'm being unnecessarily frugal because I won't be using this particular JeeNode for anything except timing detection.
The ultimate goal (many swearings and hair tearings further down the road) is to reverse the situation and produce an electronic, programmable, ignition driver which will set the spark timing on the fly as part of a modular engine management and fly-by-wire system for a VW kever ... silly, but fun :) ... but because of this, buffering the output isn't an option. The revs of an engine can go from 650 to 6500 and back in 2 seconds and the spark timing will shift from 7 degrees BTDC to 40 degrees BTDC across the range. The timing has to keep up with, and in precise relation to, the revs. If not, then at best you'll get serious inefficiencies and lost power, and at the worst, the distinct possibility of an expensive 'bang' somewhere deep inside all the spinning metal ...
The whole thing has to be as near real time as I can make it.
I'm loving it ... it was 1980 when I last did any real bit crunching and I needed to start counting cycles :) I'm sure I'm missing something along the way, but its all a learning process.
Time for me to start curling up in bed with a good data sheet or two .....

Posted 02/06/2010 20:36:40
jcw

Ok, so timing in those 30° is tight. Can't you use the other 330° for that part? Or is a single transmission by itself keeping the processor too busy for more than one rotation? In that case, I can see why you'd want a dual setup. How about a dedicated ATtiny to do the time critical stuff and send out data serially or via hardware-assisted I2C?

Posted 02/06/2010 21:46:38
radiotrib

Hi J-C and thanks for the fast responses ... in fact, for the cost of a JeeNode or a RBBB it's not worth bothering to interface a tiny. A rev counter costs well over 100 euro and none of them have spark timing as well, so a couple of 15 euro jeenodes is no big issue :) .. and I thought the uSec clock resolution was finer on the AT Mega.
I was thinking about it all again last night, and you're right. The 330 degrees represent about 7 mSec at 8000 RPM so if I can get my comms inside the uninteresting part of the rotation all will be well.
I think the real problem is just that I'm thinking like a PHP programmer not a machine level programmer (i.e. sloppy - unaware of resource consumption) and I'm still not trying to visualise my code in terms of processor usage.
I've got over a year to get it all right, and the other instruments are pretty slow in comparison with this one (2 x air pressure, 4 x temperature, 2 x oil pressure, 2 x O2 sensor, 1 x throttle position sensor + 2 x throttle servos ) so I should be able to run all those off one node and dedicate most of my time, and one whole Jeenode to the timing issue.
The instrumentation will probably be running on a linux computer embedded in the dash, otherwise using 7seg and bar code displays driven by a dedicated Jeenode ... so displaying the data should be no problem either.
Cheers
Kevin

Posted 03/06/2010 06:42:16
radiotrib

My bad .. I forgot something !!
To clarify ... every rev == 2 sparks on a 4 cylinder engine, so it's actually a 180 degree timing cycle not 360 and as a consequence the interrupt will occur at twice the rate ... that's 3.5 mSec at 8000 rpm(still should be enough time to communicate the result I think) ... Of course, the spark timing remains at +- 500 uSec...

Posted 03/06/2010 12:45:47
radiotrib

DOOOooohhh .. I never noticed the pulse() method until about 5 minutes ago !!!
Ah well ... back to the drawing board ...

Posted 03/06/2010 13:33:04
radiotrib

SORTED !!! ... I was even able to afford myself the luxury of using a few floats in the loop so I could round the integer output values instead of truncating them ... yeah!!

Posted 03/06/2010 17:53:51
radiotrib

... and still more ...
I found that when I upped the pulse rate to > 7000 rpm, the serial print routine was taking too long and the cycle was skipping a pulse. Consequently I had a rev counter running at around 50% of the actual revs. I fixed that by sampling two pulses and the space between them ... A little extravagant, but now I can report up to 25000 rpm without a glitch and with accurate spark timing ... but I lose one pulse per sample.
A case of standing too close to the coal face ...
The reason for my obsession with sampling every pulse was caught up with the future need to manage every pulse when actually generating spark timing rather than reporting it. Consequently, I didn't recognise the evident fact that the timing generator would only be detecting a rotation pulse and flicking a pin about 2.5 to 48 milliseconds later ... so there would be no communication overhead in this case.
Happy bunny time ...
So now I have a working rev counter and timing reporter which can communicate the results faster than the eye can detect jitter on an instrument, and the plan is in place for the timing driver as well ....
Now I feel ready to start on some simple sensor interfacing and display drivers ...
Thanks J-C :)

Posted 04/06/2010 08:12:15
altprog

Hello,
I fond the matrix in "library -ports" very usefull. Perhaps you can add the interupt-pins like: Int0 ? PD2 = Pin 2 INT1 = PD3 = Pin 3
By the way, resding this page, I see often only Questionmarks in the description of the libraries such as:
?class RemoteNode ?class RemoteHandler ?class RemotePort
Same thing in manual class millitimer. Is this my browser? (Firefox)
Thanks altprog

Posted 21/08/2010 12:45:10