Wireless Sensor Node with MSPG2553 and 8-pin NRF24L01+ module

[t0mpr1c3 91]

This is my first time designing a PCB for MSP430. I really like the NRF24L01+ booster pack but I would like something smaller to use for remote temperature sensors. With that in mind I've designed a 24.5 x 50 mm PCB (2 on a 5x5 cm prototype) featuring MSP430G2553 and an adapter for a 8-pin NRF24L01+ module using essentially the same pinout, with the intention of using the Spirilis library. There's a jack socket to connect a 1-wire sensor (e.g. DS18B20), a 4-pin header to connect a temperature/humidity sensor (SHT22 or similar), a programming header that gives serial access, and 3 other general purpose I/O pins. You could connect a thermistor or LM35 to the jack socket by leaving off the 4.7K pullup resistor on the data pin. Power can be supplied by a CR2032 coin cell or via a mini USB and LDO voltage regulator.

 

The repository is https://github.com/t0mpr1c3/wisenode although I haven't put up any documentation yet, just the Eagle files. I'm really very new to circuit board design so please if you can see any improvements do leave a comment for me. Thanks!

[roadrunner84 466]

It's looking good! Quite an impressive circuit for someone new to circuit design!

 

I had three questions/remarks:

- Why do you use a stereo jack, while you actually use two conductors, wouldn't a mono jack be more appropriate?

- You connect the output of your USB power converter directly to the CR2032, which will essentially try to "charge" the cell. To avoid this, you could connect a diode from the coin cell to 3V3 and a diode from U1 OUT to 3V3. This will suffer you some voltage, but when using germanium diodes, this will be only 0v3, which leaves you with 3v0 (or 2v7 from the coin cell) to use. I'm not familiar with the MIC5025, but I suspect the BP pin to be "backup power", couldn't you connect the coin cell to that pin instead?

- TEST is left floating in most circuits, as in yours. This works most of the times. I have learned however that you'd better pull it down with a 47k resistor to ground, just in case to keep the level steady in noisy environments.

[t0mpr1c3 91]

Thanks RR! Can I use Schottky diodes for that purpose? The Micrel Vreg does have an enable pin which I am currently not using, but I could perhaps organise things so that power from the USB port is disabled with a battery present.

 

As I understand it, a mono jack would restrict a DS18B20 to parasitic mode which has a limit of about 85oC, but I need to measure temperatures up to 100oC. I will have to check though. The three connections might come in handy for other purposes I suppose: come to think of it, it is not difficult to get hold of 4-contact 3.5mm jacks.

[ike 53]

"Can I use Schottky diodes for that purpose?" 

Of course you can. Germanium diodes are thing from the past. There are now Schottky diodes for RF applications and Schottky diodes for power applications. 

 

So to be useful nodes have to be cheap and you need many of them. On ebay you can buy some cheap solutions. All you need is:

1. 10 pcs of msp430g2553 - at 8MHz you should be able to run them until you drain batteries at about 2.0V. 

2. "10pcs nrf24l01+" about $12-$13. Those modules can run at 2.0V too.

3. "10pcs pcb paper" about $1.58 - they are crappy http://en.wikipedia.org/wiki/FR-2 but they are cheap.

4. "10pcs AA  battery holder" about $4.86

And you have 10 cheap working nodes. Maybe you don't need 32khz xtal. Use VLO at 12mhz to wake up node every 2 minutes or so  to say: "I'm alive", to send collected data and then enable RX mode for about 100mS to read message queue for that node. Here is mock up of the setup:

[t0mpr1c3 91]

Well, that's a possibility but I have no intention of soldering 20 of these things on perfboard when I can get double sided boards manufactured for $0.50 plus shipping. I have a load of those perfboards for prototyping: they aren't even flat. I like that rechargeable AAs are cheap but they are also bulky. One improvement I could certainly make is to look around for some smaller coin cell holders.

 

The watch crystal is a bit of a luxury. If I wanted a smaller footprint I would get rid of that first. Timing in seconds would be nice but it is not essential.

 

Would this kind of diode arrangement do the trick? The spare pin in the Vreg can take a bypass capacitor to ground to reduce noise.

 

[roadrunner84 466]

I'd prefer to use diodes on the commong Vcc, instead of the common Gnd. But you'd need a common anode type instead of a common cothode type dual diode. This will probably just work fine.

 

If you want to go for cheap: there are two major types of coincell holders: the "real" ones, in which you clip the coin. And the "spring" version, which are basically a piece of spring steel bend to clamp a coincell between the spring and the PCB. The latter can be got at dirty cheap rates through the right places.

 

If you want to get rid of the crystal, you might try to "sync" time over the network from one or a few nodes that do have the crystal in place. If you sync, say, avery quarter of an hour, you could get fairly accurate timing, even in nodes running from VLO.

VLO suffers from temperature changes, but in most environments you don't have changes so rapid that you couldn't compensate within half an hour.

[t0mpr1c3 91]

I share your preference. I happen to have BAT54A in my bits box and just wanted to check I had got it in the right place. Also the way i have the PCB laid out it is easier this way.

 

I will have a star-shaped network and could sync the nodes to the master.

[t0mpr1c3 91]

Thanks for the feedback on this design. I will send it off to FusionPCB at the weekend.

[jpnorair 340]

Be careful with coin cells.  Coin cells usually can't source much current for very long.  If you use coin cells, you'll need to engineer the firmware more carefully to make sure to go into low power modes as often as possible, both for the MCU and the radio.

[t0mpr1c3 91]

One problem is the voltage divider that is monitoring the positive rail voltage. It will be constantly draining a little bit of current.

 

One possibility might be to move R1 to the emitter of Q3 and monitor the voltage at the collector of Q3, adding the voltage drop across the LED to get VCC - what do you think?

 

2xAA/AAA battery boxes can be attached to GND/VCC headers if I need to.

[jpnorair 340]

The LED on SCLK is not going to be very useful.  The LED on IRQ is maybe useful, maybe not.  You'll still need a logic analyzer to debug the SPI, and generally with these RF transceivers the SPI activity isn't 1:1 with RF activity.  Usually there is a FIFO that is loaded, so, the blinking of the LED might be imperceptible.

 

Maybe you're having a pin shortage, but I would tie the LEDs to firmware rather than hardware.  I've spent a lot of time working on WSN firmware (links below).  My practice is to use a green LED during the TX process and an orange LED during the RX process.  The colors aren't really important, but if you are trying to characterize a MAC with two LEDs, this is the best way.  For debugging, you'll want a logic analyzer.  The Logic8 is a decent one.  I mostly use an Intronix model, but Logic8 is much better value.

 

On the MSP430, you can drive the LEDs active high or low.  You can skip the external transistor in the active low configuration by configuring the pin as a floating input (HiZ) for the off-state, and a logic-low output for the on-state.

[spirilis 1,265]

On my nRF24 boosterpack I have an IRQ LED driven by transistor (PNP so it lights when pin goes low), and an LED driven by SCLK. The latter is handy, you see the flickering. It has an NPN driving it fwiw (base triggered by SCLK line thru 10K resistor)

 

Sent from my C3PO via Tapatalk

 

 

[t0mpr1c3 91]

Yes the LEDs are taken straight from the boosterpack.

 

I do like the suggestion of software controlled green for TX, orange for RX (or whatever colors). I will think about that possibility.

 

I have one of oPossum's LP boosterpack 6 channel logic analyzers  :thumbup:

[t0mpr1c3 91]

Changed the LEDs as suggested and added a tactile switch, so that the sensors can easily be programmed with an identity / location.

[jpnorair 340]

Good thinking: human interfaces (like switches) are always nice to have for wireless prototypes.