Jump to content
43oh

bobnova

Members
  • Content Count

    161
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by bobnova

  1. Oh yeah that would be a great way to go.  I was going to do a Tiva/Stellaris port at some point but didn't bother with it.  Haven't done enough with them since to make it worthwhile.  (On to other hobbies these days it seems)

    Thread is a little old I realize, but the current library works great on Tiva/Stellaris boards.

     

    I've used it on the following launchpads:

    2553

    5969

    Stellaris

    Tiva-C 123

    Tiva-C 129.

    You have to change the pin assignments to match the launchpad pins and play some games with where the SPI library resides on your computer, but other than that it works great.

     

    Right now I have it communicating with an Arduino running the RF24 (http://tmrh20.github.io/RF24/) library. The two libraries use reversed orders for addresses and have very different default settings for the radio, but work once you get those straightened out.

  2. I wasn't able to get a NRF24 working with a MSP430G2452, let alone a 2231.

    Not really sure what the 2452's problem was, easiest guess is RAM of course, as I don't know how much the library consumes.

    I did a quick count and it seemed like enough, and went through the library a bit looking for references to HW at the 2452 doesn't have, but never really found much.

     

    Doesn't surprise me much that it won't fit a 2231, those things are tiny as I recall.

     

     

     

    As a note, when the library says that the NRF24 is in low power mode it really means it.

    I have one outside right now running off a AA Power Board from Jeelabs (boosts >0.9v to 3.3v), connected to a 2553. It checks temp and light and battery level then sends out a packet containing that plus a count plus an ID number every ten seconds and sleeps the rest of the time. I hacked things up a bit to allow LPM3 in energia and set a timer running to wake it back up every ten seconds.

     

    I put it outside in a plastic bag (rainy season) with an alkaline AA I found lying around that had ~1.32v unloaded.

    After about eight weeks or so (more?) it's still running and the battery has gone down by about 30mV according to the node.

     

    Very happy with the library am I.

  3. Breadboard/long wire related inductance is the majority of it I'd guess. You get some of that just from the transistor(s) itself too.

    A very small cap between the blue trace and VCC or GND (doesn't matter as long as they're both clean. I'd probably use GND) will eat a lot of that spike without slowing the rise/fall times too much.

    My experience has been that even 10nF is enough to damp down spikes like those if there is some resistance in series with the incoming voltage (there is in this case, inside the touchscreen). That may even be too much, it's worth playing with.

    You mileage may vary of course. It's hard to say how long the spikes last on that scope setting.\

    If they're the sub-microsecond-duration sort I'm thinking of they are very easy to kill with small caps. The longer they last the harder they are to kill.

  4. It's all good. Hard to get tone/mannerisms in text so I try to assume the least offensive interpretation is true.

     

    What I'm planning on doing is having a (big) variable with the total ms (or maybe tenths of a ms) of fuel injected into one cylinder, so each time the injector fires the firing time is counted (if I can get a sensitive enough scope in there to measure how long it takes to open, I'll subtract that from the open time) and added to that running variable.

     

    A probably-won't-compile-and-definitely-won't-work semi-pseudocode/semi-energia/semi-ccs example:

    unsigned long totalFiringTime;
    unsigned char thisFiringTime;
    boolean injectorFired = false;
     
    while(1){
      thisFiringTime = 0; // It's being zero'd constantly so that it'll be zero when the injector fires.
     
      while(injector == firing){  //
        delayMicroseconds(100);  // wait 100 microseconds.
        thisFiringTime++; // mark off that 100microseconds.
      }
     
      totalFiringTime += thisFiringTime;
     
    }
    

    It'll need Awesome Features like a way to report the collected data and track/report other things too of course, but that's the basic idea.

    So at 800RPM for a minute with a 2ms injector pulse it'll report ~800ms of fuel injected, while a minute of 5000rpm and 2ms injector pulses will report 5000ms of fuel. (One pulse every other RPM in this theoretical motor. Real world may well be different, but it'll be the same across all four cylinders at a given moment of time so that's OK I think).

    What units I use will depend on testing. I just ran some numbers through calc.exe and it looks like if I assume my civic has 240cc/min injectors (I think it's somewhere around there) a full tank of fuel is ~189 minutes or 11356 seconds. Given that I have four injectors running but am only tracking one, it'd take ~2839 seconds to empty my fuel tank. If I pretend an unsigned long is 4 billion exactly that suggests that I should use a unit of 0.00000070975 seconds for best accuracy, or ~701ns.

    That seems overly exact, I could see going for microsecond accuracy, should be easy enough to feed the ESI timer a 1MHz clock to count with. That'd give me enough exactitude to take the injector opening time out without mucking with the fuel pulse too much.

    Using microsecond accuracy justifies the ESI though, so that's nice!

     

    It's all lovely and theoretical still of course. I haven't had time and the required brainpower available to actually muck with it since the failed attempt at UART functionality.

    Loving the new job, but having spent much of the day figuring things out makes it harder to get into the swing of it at home!

     

    The more I think about this theoretical project the more I want to have it though.

  5. To be fair, the information is all there, but the organization confuses the hell out of me and the examples are pretty much all in assembly.

     

    Thank you, by the way, for de-mystifying the ESI state table. I've managed to mostly wrap my head around how that table works at least.

    Assuming of course that you're right about it and not just lucky. On the plus side for me even if it was luck, I'm more likely to be using quadrature than 3 sensor LC :D

  6. That makes sense. Probably worth testing to make sure you can get 0 and 1023. It can be trickier than you'd think, the difference between 0 and 1 at the 3.6v the launchpads typically run at is only 0.0035 volts.

     

    I noticed the OR largely because I've been in that trap in almost exactly that situation and driven myself nuts trying to work out what was wrong.

    It can be very helpful to take out a calculator and notepad and manually test a program. Takes a bit, but it turns things like that up.

  7.  

    if(value >= (oldValue-sensitivity) || value <= (oldValue+sensitivity))

    This will always return true.

    This method will do what you want if you switch things around a little bit. You want to check to see if the new number is less than X - sensitivity or more than X + sensitivity, and if it is then you run your code.

    If it isn't then you return false as the number is still within the sensitivity range.

     

    [code]if(value <= (oldValue-sensitivity) || value >= (oldValue+sensitivity)){
       doStuff();
       return true;
    }
    else{
      return false;
    }

    Just as an example. Please do note that the above has not actually been compiled/run.

     

     

    Or do what abec. suggested, the end result is the same.

     

    I'm not sure you need to check for 0 and 1023 specifically. If the last read was 1023 and the next read is also 1023 that will fall within the sensitivity range and be ignored.

    Maybe I'm missing something there.

     

     

     

    If you have time, do a few more samples with a bit of time between them.

    If I can I like to sample decently often over a ~17ms time period to get rid of the 60Hz background EMI.

    A running average can be a nice tool for this sort of thing too. Take value and add the last-read value then divide by 2. Very low memory usage, with decent long term averaging.

    A small cap between the ADC input pin and GND or VCC can go a long way too, especially if it's a high resistance slow changing (relatively) input.

  8. Even less time! Amazing!

     

    Did figure out exactly what I want to do with the ESI bits though. I'm thinking that their ability to start/stop a timer to measure a pulse width is going to be used to collect ON time of a fuel injector.

    For the early going I'll just measure fuel in seconds of flow per distance, or seconds of flow per trip. It won't be something that can be converted to MPG, but it'll be easy to see the difference driving style/etc. makes.

     

    Having the ESI do the timer running means not having to use CPU cycles to do it but still getting a good solid time on it, which I like.

     

     

    Spent some time trying to get the UART transmitting for debuging. Didn't manage to. I need to pry the setup out of the Energia FR5969 setup bits and try that.

  9. It seemed high to me too, it's on the high end of normal, but within the normal range.

    Under ~30PSI is frowned on, most systems aim for 40-60. There's some more data here: http://www.cpuc.ca.gov/NR/rdonlyres/A172EAE5-8520-468E-85D8-67E9BA3FC984/0/WaterSupplyRequirements.pdf page 7 gives some example numbers.

     

    If the generator is on the nozzle side of the valves rather than the mains side of the valves you're absolutely correct, it'll never see anything close.

    I was thinking of using it on the mains side of the valves, not sure why.

  10. Using CCS type calls for the second interface might be the easiest, which isn't saying much. You'd be writing a second interface for it parallel to the Energia interface.

    Best bet might be to modify Energia to use setModule on the lower grade MCUs and the submitting it to the github to see if it makes it in.

    Bit of a pain in the rear.

  11. Minor update, did some very preliminary work on getting a FRx9x9 (currently, 5969) set up and timers running for pulse width counting / display update intervals / etc.

    These things are far more complicated internally than the 2553s, that's for sure. It's been a bit of a headache, but I'm making headway.

    It doesn't help that I've been almost entirely using Energia up to this point. Using CCS-level code inside Energia is all well and good, but Energia still takes care of all the basic setup, so I've had to figure out how to get all that going.

    I think I've gotten most of it at least.

     

    I start a new job on Monday, so things may go slowly. I really want to have this for my car (as I think I mentioned, my car has no tach at all, which frustrates me), so it will get done!

  12. Cool project. I've been eyeballing water consumption monitoring as a project I want to try sometime, so I'll definitely be watching this!

     

    On the electrical side there will probably be enough space and free processing power on the MCU that sits in the electrical box (or on the wiring) with the sensors to chew on the data and spit out either a hall effect style "tick" every X watt/seconds (watt/minutes, watt/hours, whatever your units end up being), or send a packet every X seconds saying that Y watt/whatevers have been used. That would leave the ESI bits on the base station free to deal with the water sensors.

    My basic thought process is that anything that can run a radio should be able to turn even a basic amps/volts over time sine wave into a digitally storeable / transmittable number in the ~16ms period a 60Hz sine wave gives you. Monitor one full cycle, spend the next cycle calculating, send the data off every 60 cycles. Something like that.

     

    I'd love to see water sensors powered by water flow.

  13. I don't think the FR5969 has ESI fyi ... just the FR6989 or whatever.  The header files (grepping/searching for MSP430_HAS_) elucidates this.

    Well that's awkward. TI's combined datasheet/user guides frustrate me for this reason. I'll check that. Thanks!

     

    I like your idea. May I suggest adding a manifold pressure sensor to the design?

     

    You could program the shift light to illuminate at certain RPM for over-revving protection and use manifold pressure as another trigger for the light, such as during partial throttle application. When you press the pedal down some, manifold pressure will increase (less vacuum = more pressure), and RPM will climb. During this period, manifold pressure will decrease (more vacuum) as the RPM approaches the peak power output at that throttle opening angle. So, if you watch manifold vacuum until it's rate of change slows, that is the point where you could trip the shift light. Don't know if I'm making sense.

     

    MPG is fairly easy to implement: speed divided by fuel consumption, both measured in a common unit of time such as seconds. Instantaneous would be miles per second divided by liters (gallons) per second; accumulated would be the running average of all instantaneous calculations up to that point. Calculating fuel consumption will require knowing fuel pressure at the time of sampling the injector pulse-width and the injector flow rate at that pressure. Most vehicles have variable fuel pressure such as 34PSI at idle increasing to 43PSI, correlated to manifold vacuum; turbo/supercharged vehicles can have peak pressures nearing 80PSI or more.

     

    You could also sense the fuel level and extrapolate fuel consumption from that, if you can accurately calibrate the fuel level sensor. A Kia I recently rented did that- it would reset the accumulated fuel economy tally when you filled the tank. You could get fancy and do a 'lifetime', 'tank', and 'instant' economy tracking.

     

    Okay, I'll shut up now. :)

    The MAP sensor is definitely on the list of possibles as well, as you mentioned it's a lovely load indicator, more specific to engine load than the TPS.

    Honda typically runs the fuel pressure at 38-44 PSI over intake pressure, so I'd need to measure that and find out exactly where it is with regards to intake pressure. After that it's essentially static as far as fuel flow goes.

    What you're talking about is pretty much exactly my thought process. I know the MPGduino already exists and does something similar already, but that's no fun :D

    Thankfully (or not...) the vehicle in question is a 100% stock 97 civic, very simple car. No forced induction or sneaky variable runner lengths or anything.

    Fuel consumption based on fuel level is something that hadn't occurred to me, that could be interesting to pursue. The more I think about it, the more I like this idea.

    Thanks for the ideas!

×
×
  • Create New...