bobnova

I've been playing with NRF24L01+ modules and launchpads. I've got 'em to where they can run and send packets on a (&*@#% little solar panel out of a harbor freight solar path light, and make it through the night on a 300mAh NiCd. Next up was improving their range, as the PCB trace antennas aren't especially good (even more so when you have metal walls to punch though, like I do).
 

Cut traces, soldered mini-coax from a dead WiFi router in place.
 

Built a mini-yagi!
 

The test package, a MSP430G2553 launchpad, a JeeLabs AA power board (3.3v boost converter, extremely efficient and low quiescent current), a $1 NRF24 board, and the Yagi.
 
Works great! Over doubled the range I get through the wall, it went from ~60-80' depending on direction to 200-240'.

I've been playing with NRF24L01+ modules and launchpads. I've got 'em to where they can run and send packets on a (&*@#% little solar panel out of a harbor freight solar path light, and make it through the night on a 300mAh NiCd. Next up was improving their range, as the PCB trace antennas aren't especially good (even more so when you have metal walls to punch though, like I do).
 

Cut traces, soldered mini-coax from a dead WiFi router in place.
 

Built a mini-yagi!
 

The test package, a MSP430G2553 launchpad, a JeeLabs AA power board (3.3v boost converter, extremely efficient and low quiescent current), a $1 NRF24 board, and the Yagi.
 
Works great! Over doubled the range I get through the wall, it went from ~60-80' depending on direction to 200-240'.

I've been playing with NRF24L01+ modules and launchpads. I've got 'em to where they can run and send packets on a (&*@#% little solar panel out of a harbor freight solar path light, and make it through the night on a 300mAh NiCd. Next up was improving their range, as the PCB trace antennas aren't especially good (even more so when you have metal walls to punch though, like I do).
 

Cut traces, soldered mini-coax from a dead WiFi router in place.
 

Built a mini-yagi!
 

The test package, a MSP430G2553 launchpad, a JeeLabs AA power board (3.3v boost converter, extremely efficient and low quiescent current), a $1 NRF24 board, and the Yagi.
 
Works great! Over doubled the range I get through the wall, it went from ~60-80' depending on direction to 200-240'.

Roughly speaking, don't push it over 8mA, and not more than a few at a time.  Prefer to keep it <4mA even.

That explains something at least.
I'm hoping my alarm issues were due to subtle differences between A and B, as I thought I understood it based on the datasheet.
 
I'm hoping I can steal some time to play with this library today.

Very cool! I'll definitely try this out.
I've been kludging my way through the FR5969 RTC (and apparently looking at the wrong datasheet section while doing it, oops, maybe that's why I couldn't make the alarm function work...) and found it to be quite nice.
 
Having a library surrounding it would definitely make things easier, and having read the readme included with said library it looks nice and powerful as well.
 
Thank you!

I read through a couple of your linked articles, they are going to be useful to me.
Thanks!

Hi all,
 
I have made a couple of MSP430 Tutorials and thought I would share the links here:
 
ADC tutorial and example code
I did this one awhile ago and just covers the ADC with 3 example codes, multiple channels, multiple reads etc
http://coder-tronics.com/msp430-adc-tutorial/
 
Timer tutorial and example code
Only posted recently and covers both timers on the MSP430G2253, again with 3 examples PWM, interrupts etc.
http://coder-tronics.com/msp430-timer-tutorial/
 
Programming tutorial covering the GPIO and peripheral registers
I found this all a little confusing when I started out and had a question from someone recently, so thought I would try and break it down into simple terms.
http://coder-tronics.com/msp430-programming-tutorial-pt1/
http://coder-tronics.com/msp430-programming-tutorial-pt2/
 
Switch Debouncing tutorial with several MSP430 code examples
Just some useful information on switch debouncing as well as some code useful code examples
http://coder-tronics.com/switch-debouncing-tutorial-pt1/
http://coder-tronics.com/switch-debouncing-tutorial-pt2/
 
Hopefully they are of some use  ,
 
Cheers,
Ant

I don't know if there is an equivalent, then again I didn't know those existed in the first place.
I've been learning the direct port manipulation methods.
 
On the speed end of things, I tested a G2553 at 16MHz with my scope.
 
This sketch:
void setup() {   pinMode(P1_0,OUTPUT); } void loop() {   digitalWrite(P1_0,HIGH);   digitalWrite(P1_0,LOW); } Toggles the pin at ~119kHz, 8.39

PC SATA power connectors for power, routed to marked power rails for 3v3, 5v, 12v, ideally with PTC fuses inline for overcurrent protection.
Better, tighter, connections.
FTDI would be nice.

There we go, that's perfect.
Serial.whatever for talking to the computer.
Serial1.whatever for the camera.
 
For using software for the computer and hardware for the camera what I was thinking was to remove both jumpers and make jumper wires to attach the softwareSerial ports to the programming section and more jumper wires to attach the HW serial pins to the camera.
 
Hardware for both is easier/better, though.
One thing to note on multiple HW serial things is that at least on the LM4/TM4 launchpad they all have to run at the same baud rate.

Might want to check out Dangerous Prototype's "Dirty PCBs" too. 8-12 10cm x 10cm PCBs for $25. 8-12 5 x 5 boards is $14.

I definitely recommend laying your hands on an oscilloscope of some sort. It doesn't have to be an expensive, "good", one. A $65ish DSO201 handheld thing is fine, or a similarly priced USB scope. It may not be especially accurate, but it'll be decently consistent and that's good enough for a lot of work.
Another alternative is to buy a used standalone scope, mine came from the university of washington and appears to have last been calibrated in 1977. Despite that, it works great and is surprisingly accurate and precise. It was $35 + $35 of shipping.
 
I've never used the sound card method, but I've heard they're not bad at all. I would grab a cheap sound card of some sort to abuse rather than using your motherboard's on board card or an expensive "nice" card, just because it would be unfortunate to blow up something you cared about.
 
I've used mine for an incredible variety of things, I can't imagine not having one now.
 
 
 
 
(EDIT: On consistent vs accurate in my mind. When I say accurate I am thinking: A 5.0000v signal is read as 5.0000+/- a small amount. When I think consistent I am thinking: A 5.0000v signal is read as 4.8588 (or something else not 5.0000), but it's read that way every single time. Accurate to itself, essentially)

Given the cost of the boosterpack ($20 and out of stock) plus a F5529 ($13), you might consider buying the TM4C129 Tiva-C Connected Launchpad instead, it's $20 and has native Ethernet, plus a very large/fast microcontroller and a ton of pins.
I realize we're on 43oh and it's a Tiva thing, but still.

Given the cost of the boosterpack ($20 and out of stock) plus a F5529 ($13), you might consider buying the TM4C129 Tiva-C Connected Launchpad instead, it's $20 and has native Ethernet, plus a very large/fast microcontroller and a ton of pins.
I realize we're on 43oh and it's a Tiva thing, but still.

If my reading of datasheets and energia device files is correct you can solder the optional 32.something kHz crystal onto the launchpad and use that as a clock source for one of the timers to use with PWM. At that point you could have anything down to a 0.5Hz PWM output, I think. Maybe even less if you feed it through a /8 divider first.
Low speed PWM shouldn't be an issue.
 
I'm not especially well versed in this business yet, so I may be way off base.

twi.h has a speed setting early in it.
It looks like you might be able to define "TWI_FREQ" in your code before you include Wire.h (which includes twi.h, which checks to see if TWI_FREQ is defined and if not, defines it) and set the speed that way.
twi.h kicks off with figuring out what sort of serial interface the MCU has, then hits the speed section:
#ifndef TWI_FREQ #define TWI_FREQ 100000L #endif My guess is that it's in Hz, 100kHz seems like a reasonable default speed.
Will it work faster? I have no idea.

Digging through the Energia source code:
(energia-0101E0012/hardware/tools/msp430/msp430/include/msp430fr5969.h)  #define LPM4_bits           (SCG1+SCG0+OSCOFF+CPUOFF) #define LPM4      _BIS_SR(LPM4_bits)     /* Enter Low Power Mode 4 */ Is this what you want to happen, or do you also want interrupts?
 
If you look at this thread from two years ago (or look at msp430fr59xx_p1_03.c in MSP430ware), it looks like you also want to enable interrupts: _BIS_SR(LPM4_bits + GIE); // Enter LPM4 w/interrupt  

Isn't the watchdog timer running all the time?
 
That could be the source.

If this forum software supports it, making the Stellarisiti Energia "forum" into a link to 43oh's Energia forum might be the way to go.
I too agree that having two forums is a little rough sometimes.
I read both and use both classes of chip, so it's not a huge deal, but it's a bit confusing at times.
 
Also agree on putting chip designation in the post title. With this large of a variety it's important to know.

As a note, I've found that generally "if" is an expensive thing to say if (heh) you're looking at time consumption.
Same for "for". Haven't checked "while", but it probably is too.
How expensive it is depends on the chip and the variables you're comparing of course. If you're comparing bytes on a 16bit chip that ought to be faster than comparing longs on said 16bit chip, but may not be on a 32bit chip.
 
That said, writing code that doesn't say "if" is a good trick.
 
 
Oh and I tested the code (modified to work on a launchpad without extra stuff attached) on a scope, and got ~900ms/loop also.

I've found that I have COM port issues if I have the serial monitor open when I plug a launchpad in.
That's guaranteed failure, like the above.
The solution for me is to unplug the launchpad, close the serial monitor, and re-plug the launchpad.
 
That's the only similar thing I've run into.

Just thought I'd check in here and say THANK YOU! Excellent library, easy to use, easy to set up, etc.
I have it working now, sending packets from a g2553 to a Tiva-C, works perfectly.
 
I used the pin map chart Maddox675 posted, as I bought the modules alone rather than with a boosterpack.

I'll certainly try! I
Never done anything on github but download, so I'll need to make an account and such.
I'll see what I can do.

I don't know if you're still around or not, but I got a IoT launchpad a couple days ago and have been having similar issues with a webserver program based heavily on the demo/example program in Energia (BarometicPressureWebServer), which uses the same core code as in the original post of this thread.
 
With possibly excessive use of Serial and LED debugging, I think I found the problem.
 
If I'm correct, it's due to the while loop.
It calls
while (client.connected()) { if (client.available()) { and then goes on and does things.
 
The break; statement that ends that while is inside the if (client.available). If the client never sends anything, or if the Launchpad misses it, client.available() never returns true, the IF never happens, and the break; statement never happens either. Leaving you stuck in the while loop for all eternity.
 
I've been banging my head against this issue for a couple days, and finally figured out the above. I put in a timeout to kill the connection (call break; and let it trundle off to client.stop()) after 1000ms.
void listenForEthernetClients() {   // listen for incoming clients   boolean activeConnection = false;   EthernetClient client = server.available();   if (client) {     Serial.println("Got a client");     // an http request ends with a blank line     boolean currentLineIsBlank = true;     char c;          while (client.connected()) {       if (!activeConnection){         connectionActiveTimer = millis();         activeConnection = true;       }              if (activeConnection && connectionActiveTimer + connectionTimeout < millis()){         break;       }                if (client.available()) { I've seen it hang in the while loop for a second and then reset and start working again, which leads me to believe that I've found and fixed the problem.
Bug in the demo problem rather than a bug with Ethernet or the IoT.
 
 
 
As a note, I'm absolutely loving the board and Energia support for it. Without Energia I'd be completely lost trying to do anything with this board.