Shop OBEX P1 Docs P2 Docs Learn Events
jm_freqin question — Parallax Forums

jm_freqin question

eagletalontimeagletalontim Posts: 1,399
edited 2012-01-24 22:34 in Propeller 1
Quick question... I am using the jm_freqin function to read RPM values on my vehicle and using the value returned in several other functions. I am displaying the results on my lcd display which everything is working properly 98% of the time. What I have having an issue with is the rpm value seems to glitch every once in awhile and it returns a value well over 100,000. I have the freq() called like this which runs with the LCD cog :

[PHP]
PUB LCDupdate
getrpm.init(15)
lcd.init(24, 9600, 2)
lcd.displayOn
lcd.backLight(TRUE)
waitcnt(2_000_000 + cnt)
lcd.cls
lcd.str(string("Gear: "))
lcd.gotoxy(0,1)
lcd.str(string("RPM : "))

repeat
ReadThrottle
rpm := getrpm.freq * 3
lcd.gotoxy(5,0)
lcd.str(num.dec(gear))
lcd.gotoxy(5,1)
lcd.str(string(" "))
lcd.gotoxy(5,1)
lcd.str(num.dec(rpm))
lcd.gotoxy(10, 0)
lcd.str(string(" "))
lcd.gotoxy(10, 0)
lcd.str(num.dec(throttle)) ' Display
waitcnt(10_000_000 + cnt)[/PHP]

I think it may have something to do with how I have it hooked up. I am using the same circuit as I use on the SX which is probably wrong....

[PHP]
10K
5V Ignition Pulse Signal >
/\/\/\/\/\
0
Prop Pin
|
|
/\/\/\/\/\
>GND
100K
[/PHP]

Is this a common issue with the jm_freqin function or am I doing something wrong?
«1

Comments

  • JonnyMacJonnyMac Posts: 9,198
    edited 2012-01-16 21:47
    Is this a common issue with the jm_freqin function or am I doing something wrong?

    As far as I can remember, you're the first to complain. It's an auto application, right? How do you know the problem is not noise bursts in the system? Have you monitored the input with a 'scope?

    Another thought: You don't need to know the period for a tachometer application -- why don't you just write a custom object that uses one of the counters in edge detector (counter) mode in a synchronous loop. You don't even need PASM, you could launch a Spin cog that would report the # of transitions every second; write that to the hub and the multiply by 60 to get RPM. Pretty easy.
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-17 04:34
    I am not sure about extra noise in the system since I don't have an Oscope. I think one of my friends has one and I will see if I can borrow it. Would ceramic caps help filter out the noise or will it mess up the frequency input?
  • JonnyMacJonnyMac Posts: 9,198
    edited 2012-01-17 07:08
    You would need to understand the signal before putting caps on it. At high RPMs, what is the duration of the high and low side of the signal (hint: you can use the Propeller counters in POS and NEG modes to tell you).
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-17 16:13
    Interesting. I wonder if I could build an Oscope with the Prop :p I have a few TV's laying around and a whole bunch of electronic components..... I tried to borrow the Oscope, but he already has someone else using it now :(

    Could you explain how I could use Prop to output the duration of the high and low? I am still learning the Prop language and getting better as we go :)
  • JonnyMacJonnyMac Posts: 9,198
    edited 2012-01-17 16:17
    I could, but I won't. Crack open a book. Specifically, the PEK manual by Andy Lindsay.

    Okay, here's a hint:
    -- set the counter for POS detect mode using your input pin
    -- set the FRQ register to 1 (PHS register incremented once per clock)
    -- wait for the pin to be low
    -- clear the PHS register
    -- wait for the pin to go high (PHS being updated now)
    -- wait for the pin to go low
    -- copy the contents of the PHS register -- this is how many clock ticks the signal stayed high

    Andy does a good job with counters in his book. You're going to have to dig in and do a bit of study. Yeah, I know it's a drag, but you'll be happy you did when you stop guessing at code and start designing it.
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-17 16:19
    Ok, will do :) Hopefully the book is available online :p No extra money right now... Friday is payday though!
  • JonnyMacJonnyMac Posts: 9,198
    edited 2012-01-17 16:21
    It is available in (free) PDF form. Go get it!
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-17 16:24
    Jut found it and have started reading :) I like the propScope. That is cool!
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-17 17:13
    Should I output the raw number from the PHS register on the LCD screen? Since it counts +1 per clk tick, as you said, wait for the pin to go low to ensure to start from the beginning of the high period. Let the PHS increment while high, then once the pin goes low again, I would then update the variable to display and clear the PHS value. I wonder about the display output timing vs how fast it is actually updating the variable. I guess it would be a range of numbers?
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-17 18:26
    ok... here is what I have come up with. I am not sure if I need to subtract the 624 since I am not charging a cap.

    [PHP]
    VAR
    LONG rpm
    LONG counter[100]
    ' other variables for rest of code

    PUB Main
    cognew(CountHigh, @counter)
    ' main code and loop

    PUB CountHigh
    ctra[30..26] := %01000 ' Set mode to "POS detector"
    ctra[5..0] := 15 ' Set APIN to 17 (P17)
    frqa := 1 ' Increment phsa by 1 for each clock tick
    dira[15]~ ' Pin to input
    repeat
    waitpeq(%000000, |< 15, 0) ' Wait for pin to go low
    phsa~ ' Clear the phsa register
    waitpeq(|< 15, |< 15, 0) ' Wait for pin to go high
    waitpeq(%000000, |< 15, 0) ' Wait for pin to go low
    rpm := phsa ' - 624[/PHP]

    Sound about right? The rpm variable is outputted to the LCD screen with the LCD updating cog.
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-17 19:03
    Ok, after adjusting the code to actually display something, I went out and got readings the best I could. I can't rev my engine too high since my exhaust is loud and my neighbors do not like me revving so late at night :p

    Readings :
    1000 RPM : ~ 129600 to ~130300.
    2000 RPM : Same
    3000 RPM : Same
    4000 RPM : Neighbors came out :(

    Do I need more readings or readings from the pin being low?
  • JonnyMacJonnyMac Posts: 9,198
    edited 2012-01-17 20:15
    You have to measure both sides of the signal (see my comment in post #4, above) and then add them together -- this is the number of tics in the period of your input. Divide this into 1 to get frequency. This is what my jm_freqin object does. Again, for an RPM object, though, you could use edge detect mode for 1 second, then multiply that value by 60 to get RPM
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-18 17:13
    I now have the high and low counter working but I don't quite understand the math to convert it to RPM. Right now, I am calling your jm_freqin by rpm := getrpm.freq * 3. In your freq() function, you take the clkfreq and multiply it by 10, then divide it by p which is actually fccycles. From what I think you are doing is basically this : frequency = (clkfreq * 10) / (phsa + phsb). Is that correct?
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-18 20:12
    I think I got it :) I will be testing it out tomorrow to see how it does.
  • pedwardpedward Posts: 1,642
    edited 2012-01-18 20:34
    Tim,

    Consider with a 4 cylinder there are 4 ignition events in 720 degrees.

    At 6000rpm there are 100 revolutions per second, 2 ignition events per rev, 200 ignition events per second.

    1000ms / 200 sparks is 5ms per ignition interval

    RPM = 120_000 / cylinders / interval in milliseconds
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-22 12:53
    I finally figured out what I was doing wrong and have fixed the issue. Come to find out, the waitcnt(10_000_000 + cnt) is not accurate on timing unless I added in the clkfreq. I was calling the RPM function too fast for the .freq function. I have now created a cog which updates my variables in specific time intervals for each variable. Now I am having a problem reading the vehicle speed sensor accurately using jm_freqin.

    Here is my variable updater code so far :
    PUB UpdateVariables | rpmcount, rpmread, vsscount, vssread
      getrpm.init(15)
      getvss.init(14)
      waitcnt(10_000_000 + cnt) ' Wait for full init
      rpmcount := 0
      vsscount := 0
      repeat
        rpmcount++
        vsscount++
        if rpmcount == 20
          rpmread := getrpm.freq * 3
          if rpmread < 15000
            rpm := rpmread
          rpmcount := 0
        if vsscount == 50
          vssread := getvss.freq
          if vssread < 99999
            vspeed := vssread
          vsscount := 0
        waitcnt(clkfreq / 100 + cnt)
    

    The problem I am running into is the vspeed variable that is being displayed on the screen is jumping around too much for me to get an accurate reading. The speed sensor is a reed switch which gets 5v from the ECU and outputs X number of times per revolution. I am thinking it is 4 pulses per revolution. What I am trying to find out is how many revolutions per 500ms I get at specific speeds. When I use the code above and drive at 40 mph, the reading stays steady at ~ 744 and then jumps to ~ 1180 for a few seconds, then drops back to ~744. That is way too much of a jump for me to use in a math formula. Is the time of how long it takes to process the code above my issue?
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-22 14:35
    ok, maybe I am not understanding the hz to seconds or milliseconds...

    From what I gather, the jm_freqin reads the exact time from the start of a high signal to the end of a low signal and returns that as "period". It is then put into this formula clkfreq * 10 / p where p = period. The output is how many pulses are in a 10 ms time period (0.1Hz)? Is that a constant 10ms all the time or does it fluctuate? Or.... do I have it backwards... The output is the amount of time between each pulse? If that is the case, why are my numbers fluctuating soooo much at a constant speed?

    I cannot use the BS2.COUNT on this since if the code starts counting before a pulse goes high, then the next time start counting right before a pulse goes low, the results will be different.
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-23 16:58
    I figured out the above post and have come to the conclusion that my sensor may have a problem with the contact bouncing since my sensor is a reed switch. Thanks to chetw77cruiser for pointing that out to me. Is there a way to block that out using code? Since I don't know the time interval between pulses, I can't put a delay or lock out period after a pulse since it could mess up the actual reading.
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-01-23 17:30
    A simple R-C low-pass filter on the input would probably do it. Lowpass at (150*ticks per rotation) Hz, and you should be fine.
  • pedwardpedward Posts: 1,642
    edited 2012-01-23 17:31
    http://www.ganssle.com/debouncing.htm

    You can debounce using software algorithms or with hardware. The level of difficulty depends on the severity of the noise.

    You can try the simple fixes first, like low pass filtering that was described before. Next you can do edge detection and disable the input for a moment, and re-enable it.

    You may find that simply not accepting a value smaller than a fixed preset is the best solution; throw away a narrow pulse and don't integrate it into your low pass (you should be doing a low pass to smooth out the data).
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-23 17:38
    so basically I could put a .1uf cap from the 10k to ground?
                                                          10k
    Pin  <---------------0---------0---------------/\/\/\/\/\/---------- < Input signal
                            |          |
                     .1uf =         z   100k
                            |          z
                            0--------0---------Gnd
    
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-01-23 20:06
    Yes, try that and see how it works. If you get one pulse per revolution, then a 150hz filter (10k&.1u) will top out at 9000rpm.
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-23 20:18
    The RPM circuit is good, the speed sensor is what I am having a problem with. I am not sure how many pulses per revolution it sends out. It is a reed switch as well connected to a 5v source from the ECU.
  • pedwardpedward Posts: 1,642
    edited 2012-01-23 20:48
    Aww shucks, I brain farted and wrote about RPM.

    I would bet your VSS is either a hall effect or variable reluctance. You really need a scope to tell them apart and make a proper interface circuit or you need a very good wiring diagram with depictions and pinouts of sensors.

    I found a diagram that looks close, the sensor has 3 wires and looks like a hall effect sensor. This is the output speed sensor.

    http://www.justanswer.com/uploads/al525i/2009-03-19_205426_trans2.gif

    Looks like 104 is a 5v pullup input. The other wire is ground, the 3rd is ignition power. Looks like an open collector NPN output. What do you have for a resistor on the input of the prop, going to this sensor? Where are you hooking up to the wiring harness?
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-24 04:22
    Those are the Pulse generators. I am not connecting to those since a lot of people have done a manual to auto swap and don't know which pulse generator to connect to since both have the same color wires. Right now, it is connected like the above diagram without the Cap. Have not been able to get to that yet.
  • smithdavidpsmithdavidp Posts: 146
    edited 2012-01-24 05:06
    Forgive an old mechanic from poking his nose in but this sounds a bit like the old Cadillacs that had the 4-6-8 (what a piece of junk) engines in them. They found that the sensors would pick up interference (noise) from moving engine parts, distributors, and other automotive electrical circuits. This caused the engine to be sluggish, miss, backfire and the like. The sensors were wired through shielded cable. The outside shield had to be grounded to the engine, firewall, and ecm. Any resistance found between the sensor connector and one of the grounding points would give a false reading to the ECM. The outside shield would be the problem every time. You have probably thought of this already. Anyway hope this is some use to you.
  • pedwardpedward Posts: 1,642
    edited 2012-01-24 12:37
    Tim, if you aren't using the speed sensor in the trans, what ARE you using?
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-24 16:22
    According to the wiring diagram of my transmission control unit, the wire I am connecting to is the Vehicle Speed Sensor reed switch. There are also 2 pulse generators, one is supposed to be the input shaft speed, the other is the output shaft speed. Neither of which are the speed sensor apparently. I will be switching to the output pulse generator instead since I contacted one of my vendors and they told me to basically not use the vehicle speed sensor. I don't even know where it is located since the only thing connected on my transmission is the solenoids. I just saw that there was a vehicle speed sensor wire in the plug and decided to try to get a reading from it. Apparently that is not the way to go :p Since the other is a Pulse Generator, would this also be called a hall effect sensor? That would mean I need to supply a voltage to it, and count the ticks or frequency it returns pulses back?

    EDIT : I just found out that the speed sensor is located in the dash.?.? The speedometer cable runs directly to the dash which connects to a wheel with cutouts which is then converted to give a signal to the gauge.
  • pedwardpedward Posts: 1,642
    edited 2012-01-24 18:07
    According to the diagram above, the output speed sensor is connected to +12v, GND, and the output is connected to the TCU, but with a pullup resistor to +5v. The diagram indicates an open collector transistor, which is likely a Hall effect sensor. The output needs a pullup, when the sensor is triggered it will pull the input to ground. You will need to determine which pins are what based on the TCU wiring diagram.
  • eagletalontimeagletalontim Posts: 1,399
    edited 2012-01-24 19:16
    Hmm. According to this diagram, there are 2 wires coming back from the sensor : http://www.atdsm.com/pdf/94awd.gif I also checked the sensor on the transmission itself and the wire colors match from the sensor to the control unit. I worry about running 12 volts into something without knowing it can handle it.
Sign In or Register to comment.