Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by bobnova

  1. 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. Any thoughts on the FR6989? It adds LCD and ESI over the 5969 and I have one I'm trying to work with
  3. 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.
  4. Must be the touchscreen inductance or the transistor switching itself then. I'm surprised more of it wasn't breadboard related. Those spikes look much more reasonable though, glad it helped.
  5. 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.
  6. 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.
  7. 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
  8. That userguide is not my friend.
  9. 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.
  10. 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.
  11. 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.
  12. No spam seen here. Maybe yahoo is filtering it or something. Or gmail, or whatever I used for that. I think the drawing was going to be on the 9th or so.
  13. Haven't had a ton of time, but I did have a chance to open up the TI packages last week, and had some time to sit down with the dev board and programmer today. I like both of them. LED on P1_0 is happily blinking away, energy trace is still awesome.
  14. If you have the time/energy for it your best bet is probably to set up a timer to do your timing for you. At that point you'll know exactly what its operating parameters are and it won't throw as many surprises at you as delayMicroseconds() and micros() will.
  15. Got mine too. Also a new job. Would like to get started this weekend, we'll see how it goes.
  16. I desperately want to build a laser cutter, so this might end up being something I want too. I'll definitely be keeping an eye on this. Laser etching pcbs would be glorious!
  17. @@abecedarian I've been wondering what to do about that too. So far it hasn't become an issue for me, but I could see it being a problem very easily.
  18. 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.
  19. 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.
  20. Check your water pressure first, it says it's rated for ~79PSI maximum and ~65PSI normal operating. That may be plenty, but my house is in the lowlands and runs 68-73PSI, pretty close to the maximum. Other than that it looks perfect, tons of current, plenty of volts.
  21. I would love to see an energy harvesting smart shoe! That'd be awesome. Even more so with wireless communication. I'll definitely be keeping an eye on this.
  22. 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!
  23. Very very cool. I'm glad to see Energia supporting deeper sleep modes. That was something I was missing. I'd worked around it by repurposing the WDT, sleeping, then setting the WDT back to how it was, but that does bad things to millis and such. Thanks for the features and the heads up!
  24. 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.
  25. Well that's awkward. TI's combined datasheet/user guides frustrate me for this reason. I'll check that. Thanks! 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 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...