• Announcements

    • bluehash

      Forum Upgrade   03/11/2017

      Hello Everyone, Thanks for being patient while the forums were being fixed and upgraded. Please see details and report issues in this thread. Thanks!
Lgbeno

New MSP430 Wireless Sensor Node

63 posts in this topic

I've wanted to create a batteries included, very low cost wireless sensor kit for quite a long time now.  I've made some attempts in the past but up until this point they were either too expensive to produce and too limited in expandability.  I think that I've finally struck the balance that I'm going to be pleased with.

 

post-30430-0-92486100-1438285554_thumb.png

 

The device is a little larger than a single AA battery, that is what it is powered off of.  It has an NCP1400 Boost converter to bump up the voltage to 3.3V.  The processor is MSP430G2553IRHB (32QFN) and it is attached to a HopeRF RF75 radio.  There are 15 GPIO available through a 0.1in female header that is sandwiched between the battery holder and the circuit board.  It plugs into a Launchpad for programming.  Footprints are available to solder on a Si7020 temp sensor, a 32kHz crystal and two LEDs.

 

I have the pins_energia ready and now looking at what it takes to make the @@spirilis enrf24 library work with it.  I'll also create my own library with some analog.io tie ins as well as a special surprise.

 

My goal is to sell these for $9.99 after I can get them debugged.  Would anyone be interested in one?

cubeberg, Fmilburn, oPossum and 5 others like this

Share this post


Link to post
Share on other sites

I completely missed the power boost - I'd ask about possible power losses over time - but I'm running most of mine off of CR2032's which don't last a month with my current code.  I should be able to port my existing NRF CCS code from my sensors over to this as well 

 

@@bluehash must be really eager #doublepost :)

Share this post


Link to post
Share on other sites

I completely missed the power boost - I'd ask about possible power losses over time - but I'm running most of mine off of CR2032's which don't last a month with my current code.  I should be able to port my existing NRF CCS code from my sensors over to this as well 

 

@@bluehash must be really eager #doublepost :)

 

Gotta love the double post :)

 

It shouldn't be a problem to get a few months of battery life assuming the processor and radio can be sleeping a fair amount of time.  The boost converter has pretty low quiescent current and AA cells have 1800 mAh or more.  

Share this post


Link to post
Share on other sites

Sounds interesting. I don't know much about the RF chip, and do *not* like the fact that firefox immediately alerted a malware attempt by their site when clicking on a link to find out more . . .

 

A mini wireless MSP430G2 "launchpad" at a dollar less than the "official" Launchpad would be really cool - Definitely.

Share this post


Link to post
Share on other sites

Sounds interesting. I don't know much about the RF chip, and do *not* like the fact that firefox immediately alerted a malware attempt by their site when clicking on a link to find out more . . .

 

A mini wireless MSP430G2 "launchpad" at a dollar less than the "official" Launchpad would be really cool - Definitely.

 

Yeah, the HopeRF website is a little dodgy, I clicked through those malware warnings for the heck of it.  As far as I know I'm still safe.  From what I can tell there are a lot of similarities to nRF24 except for cost, this one is cheaper which lets me hit that 9.99 price in low volume.  HopeRF has been easy to work with when purchasing parts, I must say that.  Again the decision about this radio was pretty much strictly made on price, once we have a solid library, it should be pretty transparent.

yyrkoon likes this

Share this post


Link to post
Share on other sites

Yeah, the HopeRF website is a little dodgy, I clicked through those malware warnings for the heck of it.  As far as I know I'm still safe.  From what I can tell there are a lot of similarities to nRF24 except for cost, this one is cheaper which lets me hit that 9.99 price in low volume.  HopeRF has been easy to work with when purchasing parts, I must say that.  Again the decision about this radio was pretty much strictly made on price, once we have a solid library, it should be pretty transparent.

Well I'm pretty much still a MSP430 newb. I did learn a bit about the G2553 on the launchpad a year or two back, wrote soem code, etc ,etc. Largely thanks to oPossum, Rick, and spirilis. Without their help it would have probably taken me much longer to wrap my brain around various aspect of the chip - In code.

 

So, an idea I've had for a long time now is to remotely monitor, and control water pressure we have on our solar pumps here ( 2 for a total of around 8-9 Gallons a minute. 500FT deep wells . . . Anyway, something like this may not be necessary. As we'd need a decent amount of power for a motor to turn off / on a diversion valve - To keep pressure under a set PSI. But non the less would be very cool, and minimal. Cost would definitely be a factor. As I could very easily do this with a Beaglebone black, but at $55 a pop . . . a bit expensive. Under $10, or even $20 is far more reasonable though.

Share this post


Link to post
Share on other sites

Yup, my theory is that if the nodes become cheap enough, we'll think of all kinda of places to stick these things.

 

For me, I'm monitoring stuff inside of BeeHives, if I can use twice as many sensors for the same out of pocket expense, I'm really happy :)

 

 

Sent from my iPhone using Tapatalk

tripwire likes this

Share this post


Link to post
Share on other sites

So heres my question, what does everyone think about bit banging the radio interface to free up the USCI port? I might make that change

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

So heres my question, what does everyone think about bit banging the radio interface to free up the USCI port? I might make that change

 

 

Sent from my iPhone using Tapatalk

Any way to make that an option ? e.g. a jumper, and different code ? Or just code that recognizes it based on how the jumper is set ? *shrug* IDK maybe unimportant.

Share this post


Link to post
Share on other sites

Any way to make that an option ? e.g. a jumper, and different code ? Or just code that recognizes it based on how the jumper is set ? *shrug* IDK maybe unimportant.

It would be pretty difficult with the 2 layer board unfortunately.

 

I'll have to sleep on it but so far I'm leaning towards changing it. Its a little of a bummer that those 3 pins have the most useful peripherals attached to them!

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

Jumpers are quite bulky, but how about an SMT 0 Ohm resistor? place three pads next to each other, the outer two for the wire to the MCU, the middle one to the RF chip. Then again, do this for each wire running to the RF chip.

Share this post


Link to post
Share on other sites

It's a 2553. Switch to uscib - I did that on my motion sensors to free up i2c.

But I like the UART on uscib :)

 

Hmmm, decisions!

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

The other thing is Energia does not support SPI on USCI_A at all.  No hooks or methods let you reconfigure it to use USCI_A.  That's not a problem for CCS users not using the Energia framework (who may be using my msprf24 lib), but for Energia it's a no-go.

Share this post


Link to post
Share on other sites

you mean uscia? (uart is on uscia)

Yeah I'm mistaken on the name. Didn't bother to look it up. I usually simplify it in my mind that there is the port with the UART and then "the other port."

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

That said, I don't see any problem in exposing USCI_B to the pins even with it being used by the HopeRF.  The RF75 does use an SPI chip select line right?  For one thing, it'd make it easy to debug your RF75 code with a logic analyzer :D

Share this post


Link to post
Share on other sites

Sorry for my ignorance, I want to write 32 bytes out of the SPI port can I load up a fifo and tell the peripheral go or do I need to load each byte into the register to shift out.

 

If the latter, I don't see as much advantage over bit banging.

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

Sorry for my ignorance, I want to write 32 bytes out of the SPI port can I load up a fifo and tell the peripheral go or do I need to load each byte into the register to shift out.

 

If the latter, I don't see as much advantage over bit banging.

 

 

Sent from my iPhone using Tapatalk

It's the latter.  The SPI peripheral can still pump out the bits faster than bit-banging IIRC.

Share this post


Link to post
Share on other sites

It's the latter. The SPI peripheral can still pump out the bits faster than bit-banging IIRC.

I would have to think about that, the Transceiver can work up to 8MHz and the CPU is running at 16MHz. My instinct tells me that I can get close if not interrupted. I'll need to test it out I guess.

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

My initial reaction is that it will come at a cost of energy usage as you're using CPU cycles instead of a peripheral - plus I don't believe the NRF library I use supports bit-bang.  Unfortunately I don't know enough to answer how big of an impact it might have to battery life, if in fact that's valid.

Share this post


Link to post
Share on other sites

My initial reaction is that it will come at a cost of energy usage as you're using CPU cycles instead of a peripheral - plus I don't believe the NRF library I use supports bit-bang. Unfortunately I don't know enough to answer how big of an impact it might have to battery life, if in fact that's valid.

I'll run some tests but I'm thinking that the impact won't be that much different because the CPU must stay active to feed bytes inti the peripheral anyway. The biggest tradeoff would be the performance hit that you are spending cycles shifting out bits instead of doing other computation.

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

I'll run some tests but I'm thinking that the impact won't be that much different because the CPU must stay active to feed bytes inti the peripheral anyway. The biggest tradeoff would be the performance hit that you are spending cycles shifting out bits instead of doing other computation.

 

 

Sent from my iPhone using Tapatalk

Right - that's what I would expect to make an impact.  I typically drop into LPM (2 I think?) while the peripheral is shifting bits.  

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now