Register

Hmm maybe I could create a program which just write a value in flash memory segment, run it on 28 pins packages before loading my main program in which i could test this value to detect the package and change assignments accordingly.

String is notorious for blowing your heap and screwing with memory.  On the Arduino forums, back in the day when I used them, the use of String was STRONGLY discouraged even on the ATmega328 with 2KB SRAM.

These is not a whole lot of dynamic memory used by the radio object when you only instantiate it but it could be enough for the String library to go into the weeds.
String on MSP430 is particularly bad since it only has 512 bytes but on top of that, the realloc() in the String library was replaced with a free()/alloc() which could fragment memory.
Could you post the output of msp430-size <your elf file>.elf?
 
If you are on windows then open a command prompt and run msp430-size on the elf file. msp430-size.exe is located in your Energia folder under hardware\tools\msp430\bin\
You can copy the path to your elf file from the black window in Energia. Be sure to turn on verbose output during compilation in file->preferences. The output should look something like this:
 
   text   data    bss    dec    hex filename     284      0     12    296    128 sketch_feb05a.cpp.elf   text is the number of bytes of flash used and bss is the number of bytes of RAM used.

Happy to hear that you got it working!
 
I will expose these variables in the next release so that the default can be overridden.

The good thing is that you are talking to the chip since Wire.available() returns 16. Now the problem is with the buffer size of I2C on the 2553 only being 16. The reason for such a small buffer size is that the smallest msp430 supported in Energia, the MSP430G2231 only has 128 bytes of RAM. Since you are on a 2553 you can increase this buffer size without running into issues. Change the buffer size to 32 in both Wire.h and twi.h and you should be up and running. These files can be found in hardware/msp430/cores/msp430/.

I suggest to go step-by-step and validate each of them.
Step 1: Try the Nokia 5110 only with hardware SPI Step 2: Try the Nokia 5110 only with software SPI Step 3: Try the RTC only with hardware I

on the MSP430G2 launchpad?  no, sadly not, the SPI/I2C peripherals share the same line.
On the newer launchpads there is an I2C peripheral in the lower left corner (pins 9 and 10 of the J1 header), and I think there's a SoftwareI2C library floating around to implement I2C in software on those pins too (for the MSP430G2 launchpad).  Might look for that one.  I think @@Rei Vilo wrote it?

Taking a quick look at the code, you'll need to change at least the following:
 
Remove this line, MSP430 can access data stored in ROM just fine without.

5: #include <avr/pgmspace.h>  
Related to this, remove PROGMEM directive here: (you might prefix the line with static)
 
23: const uint8_t daysInMonth [] PROGMEM = { 31,28,31,30,31,30,31,31,30,31,30,31 }; and access to the array has to be rewritten, original:
 
31: days += pgm_read_byte(daysInMonth + i - 1); .. 62: uint8_t daysPerMonth = pgm_read_byte(daysInMonth + m - 1); changed:
 
31: days += daysInMonth[i - 1]; .. 62: uint8_t daysPerMonth = daysInMonth[m - 1];  
And finally, replace this section with #include "Energia.h"
 
13: #if (ARDUINO >= 100) 14:  #include <Arduino.h> // capital A so it is error prone on case-sensitive filesystems 15: #else 16:  #include <WProgram.h> 17: #endif

For a monopole antenna, the resonant length is 0.25 * wavelength.  The frequency is 2450 MHz, so the wavelength is: c/f, where "c" is speed-of-light and f is Hz.  In other words, 300000000 / 2450000000 = wavelength in meters.
 
A normal monopole has impedance of 37 Ohms, which will match reasonably well with your board.  However, you need to trim the antenna more than wave/4 because there is always capacitance and inductance in non-ideal wires.  It is causing the actual wavelength to be shorter than the free-space wavelength.  The best way to get your tuning optimized in with a vector-network-analyzer (VNA).  If you don't have one (I can't imagine you do), you can do it experimentally as described above.
 
The dipole configuration described above is a balanced antenna, so it is more reliable than a monopole is.  Monopoles depend on the grounding of the device, dipoles do not.  If your board has a small ground plane or bad grounding, the monopole will have poor performance.  So, I usually recommend half-wave (i.e. dipole) antennas if possible.
 
If you want to get really clever, you could try to improve the tuning by constructing a monopole "inverted-F antenna" (IFA), but I would hold-off on that -- maybe a second project.

Might be that the batteries are dipping below 1.8V for a short interval and browning-out the MSP430, but your multimeter isn't fast enough to catch it.  Unless you're using an oscilloscope to measure...

Hi,
 
I am running an DS18B20 and an Anaren Air Boosterpack from 2xAAA batteries without problems. Dont think you need 3V minimum for a DS18B20.
 
cheers
CorB
 
EDIT: done a bit of research, it seems that below 2.7V the DS18B20 becomes less reliable. See http://openenergymonitor.org/emon/node/2331

It's actually not like that ... analog "pin" 11 doesn't correspond to pin#11 on the MCU's leads, it corresponds to an internal virtual channel.  So digitalWrite/digitalRead type of operations on pin 11 can still happen while you're reading "analog pin" 11.
 
Analog "pins" and digital "pins" are actually separate concepts in Energia, but it just so happens that the analog pins correspond to the digital pins for the first 8 (A0-A7).
 
Example from Energia's pins_energia.h for the launchpad:
static const uint8_t A0 = 0; static const uint8_t A1 = 1; static const uint8_t A2 = 2; static const uint8_t A3 = 3; static const uint8_t A4 = 4; static const uint8_t A5 = 5; static const uint8_t A6 = 6; static const uint8_t A7 = 7; static const uint8_t A10 = 10; // special. This is the internal temp sensor "analog pin" 10, in fact, is the temperature sensor inside the chip and has nothing to do with "digital" pin #10.  It's just 0-7 that correspond.  11 isn't listed there but it happens to be the "(Vcc-Vss)/2" channel.
 
What actually happens is the digital pins get resolved by some lookup tables in pins_energia.h into a PxOUT / BITx combination for manipulating the digital states, but analog input channels resolve into INCH_xx values which are written to the ADC10CTL1 register before an ADC conversion (analog read) is performed.

Voltage regulators can only lower voltages... 
For analogRead the value isn't really the Energia pin# but rather the ADC channel (INCH_xx constant), 11 just happens to be an internal "(Vcc-Vss)/2" generated channel used for measuring the MSP430's Vcc voltage.
 
Sent from my Galaxy Note II with Tapatalk 4
 
 

It seems to be working, the following sketch gives me 3.5V with USB VCC
void setup() { Serial.begin(9600); // msp430g2231 must use 4800 Serial.println("VCC value:"); analogReference(INTERNAL2V5); } void loop() { long data = map(analogRead(11), 0, 1023, 0, 500); Serial.print (data/100); Serial.print ("."); Serial.println (data%100); // this is wrong if the tens are 0 delay(1000); }

I achieved a little extra distance, but not much.  A meter or so.  I don't use them in my setup, and ~40-50ft through a few walls sounds about right.  I did however purchase a few recently so I might play with having the PA+LNA modules on both sides to see if that helps.

I guess A23 (Little 12v baterries) won't suit you. they will do 12v@80mah, down to 6~7v if i remeber correctly.  

Best way to power a msp if you have space limitations, would be a couple AAA's. a standard Alkaline AAA will do something like 1500Mah down to 0.8v, and Ni-MH ones will do 600~~1000Mah in the 1.2>>0.8v range



Quoting an old entry in the linux manual: Avoid buck converters like the plague.

In the world of small power budget, the worse thing one can do is to convert voltages.

Hi,

My project is an home automation network. The first aim was to regulate the two heaters I got in my business place. So I made a first PoC with an arduino nano and a rapsberry. The nano sends to the RPi temperature from one side of the room and the a RPI log it along with it's own temperature measurement (the 2 based on DS18B20). Communications between the two is done by 2 RF24 modules, the Raspberry got one 433 transmitter to send order to 2 Chacon switch plug onto which the heaters are connected.

On the raspberry I got a Python module logging the temperature in files and a web site in php to display temp graphs with d3.js.

As everything was ok, and with some advices from HackSpark.fr shop owner I switched to the MSP430 platform. Got now three sensors, 2 soldered and one on a bread board, communicating with one Rpi.
 
Now for the future :
Challenge 1
Part 1
At the moment I'm using ManiacBug library for Energia, and use the RF24 auto ack with the sensors writing to the same pipe (they write every 10 seconds but should at last write once a minute) so there are few packet packet collision, but to avoid this problem, and as I want more than 5 sensors, I'm gonna have to manage some network addresses and the management packet acknowledgements.

Which strategy for address assignment ? I would like to have the more flexible solution. So the sensor have to register themselves to the logger (RPi) so the loggers (in case several sensor networks) had to have the same physical address (on the RF24) as for each sensors. At init the sensors call the logger and register themselves. If there are several logger reachable, you have to accept the new sensor on the logger side. When the logger accept a new sensor it send back to the sensor a 'local' address for the network it manages.  The security concerns are not taken into account in my near future plan.
The addresses must be unique (managed by the logger) they are compose by the network id and the sensor address, so the logger or networks must have unique ids and not two long has the payload is only 32 bytes on the RF24...
The user have to manage the link between physical sensors and logical assignments ( 0x02f = the one in the garage) in case of replacement or complete reset of an existing sensor.


Part 2
One of my plan is to monitor plants soil in pot moisture  (for exemple). So the wireless is less interesting as the pot may be near each other or need 2 sensor due to their size. What i want to achieve is to have one transmitter with several wired sensor hooked to it. The perfect solution is to have the possibility to daisy chain the sensors. So here to I should have a unique "address" for each sensor had to the network.
The goal is to identify each sensor across the network and to have the possibility to request or command them.
I'm wondering which way to go, the easiest the better ;-), implementing OneWire sensors (i need distance, moisture, flow...) as i already have OneWire ds18b20 or I2C...
The wired sensor need to measure and transmit it with a stable address (keep it if it switch off) but it doesn't not to have to bee an hardware one, should be assigned on network registering. The address of the wired sensors are sub address of  the sensor. Or they could be considered has  'top' address and the wireless sensor they are attached to have to manage is packets and for attached sensor.
 
Challenge 2
The protocol : the transmission packet themselves. It has to be the more flexible possible, clear string one will be too long, for the moment I use a struct but it's to  restricting if the protocol must evolve...
And now the fun part : the images :-)
 

The Wip version
 

The soldered version
 

The logger with its screen : date, hour and three temp.
 

The graphs

I read part 1 mostly, kind've glazed over some details but at this point I want to share what I did for widespread nRF24L01+ based sensor networking.
 
My architecture includes a "packet format" with code that I include in each project to drive this protocol, both on the transmit side & receive side.  It's a lightweight "logical link control" layer overtop the nRF24's 32-byte packet format (let's call them "frames", actually, to use a lexicon similar to Ethernet).  The protocol even supports stuffing multiple "packets" inside the 32-byte frame.
 
Each logical "packet" consists of:
1 byte = Program ID, indicating what type of packet this is.  (Temperature data?  GPIO setting command intended for a remote recipient? Debug information? Relative humidity + temperature?  Water level?)  I have a manifest of program ID assignments I've made for myself.
1 byte = Packet length, indicating the size of the payload which follows.
X bytes = packet contents
(after processing this packet, if any bytes remain in the frame, the protocol interpreter goes back through the loop interpreting the next program ID, packet len, contents, etc)
 
Within the packet format, each program ID handles the contents differently but generally speaking, all of them support a 1-byte Logical Address ID that has nothing to do at all with nRF24L01+ addresses.  This ID is hardcoded into the firmware so I can tell one sensor from another, but there's nothing to say you can't make this auto-configurable.
 
For packets that request a reply from the base station, the program ID for that packet type declares that the first 5-bytes of the payload are the remote sensor's nRF24 address.  For auto-discovery purposes, this could be chosen at random on startup using some sort of random-number source.  The base station will then send the appropriate reply (reply packets will use yet a different program ID, i.e. think like ICMP Echo Request vs ICMP Echo Reply in IPv4) to the 5-byte address previously reported.  This could be used by a newly-connected sensor to autoconfigure its 1-byte ID.  Future reports from this sensor will be sent to the base station's address but with the ID of the packet contents set to the sensor's unique ID byte.  That way you can tell one sensor from another.
 
Or maybe you can forego this autoconfigure process and have a set of DIP switches or jumpers on each of your sensor nodes so you can manually configure them.  That way you know which ID corresponds to which physical sensor.  For my current installation I just hardcode the ID in the firmware and change it + recompile for each sensor I program.

Referring to the Nordic nRF24L01+ I assume?
If so, the voltage doesn't matter because internally the nRF24L01+ uses a voltage regulator (not current regulator) to provide a 1.9V reference to the chip's core.
The only thing I do recommend is making sure there's a little capacitance on its Vcc rail, maybe 10uF or so, to assist the transceiver during its startup & RF transitions.

You'll need to wire the pin to detect it. But you could wire it to (for example) the Rx pin on the debugger's UART, then you would be able to detect it when using a script. If the UART pin is space (1) the line will report it to be idle, when the line is mark (0) for at least 10 bit times the line will report frame error. So you could upload one firmware for a frame error, and the other for an idle line.
For such a script, use anything like, bash, power shell or python. This script will first upload the "set a pin" firmware, then read the Rx UART line and then flash a conditional firmware using the command line tools provided by TI.

PS: resolved. I though that by default the internal voltage was regulated got to set analogReference to INTERNAL2V5. And the reading seems correct 3.56 from launchpad and 2.66 from the two 1.2 batteries.
 
Hi,
 
I tried to measure voltage with a voltage divider as shown there : http://www.microbuilder.eu/Tutorials/Fundamentals/MeasuringBatteryVoltage.aspx
 
I measured the voltage from the launch pad (VCC/Ground) when using A1 got 4.2V reading is 417 on A4 I got 3.3v reading is 327... which seems good. So I switched to batteries after having removed the jumper for VCC/TEST and RST, the RXD and TXD are set for hardware UART. The batteries are two 1.2V 2000mAh connected to the VCC and ground pin of the launchpad. The reading should have change for 2.4V. But the reading are still around 327 (3,3V). If I unplugged A4 pin i got readings between 400 and 500 mostly around 480.
 
What did i do wrong?
 
If somebody could help me.
 
Regards.