• 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!


  • Content count

  • Joined

  • Last visited

About ghjkl67

  • Rank

Recent Profile Visitors

55 profile views
  1. Looks like I should have listened to Fmilburn all along. Adding the decoupling cap fixed the problem. I'm now able to transmit from the launchpad to the module on the breadboard. Thanks guys!
  2. I just got two new launchpads and loaded them with the transceiver codes. They work great! However, I did take note of some interesting observations: 1) The transmitter pins did not change at all. CE remained low, CSN remained high, and MOSI was pulsing just before transmitting each bit. So, it turns out the transmitter was working fine after all. 2) I took the receiver off the launchpad and used it as a standalone with the same configuration as before. No luck. 3) Something I failed to mention before was that the receiver on standalone would sometimes turn the LED on with the transmitter, but this happened rarely. It's happening again, only more frequently. So it is trying to work, but I must be missing something in the hardware configuration. Looking at the launchpad schematic, it looks like all I need is the resistor and cap going to the RST pin, which I already have. Resistor is 47K as indicated, but I used a 0.1uF instead of a 1nF as specified. I'm going to give that a try next. So to summarize, the problem is that the receiver is not working off the launchpad. Other than that, all hardware is functioning properly. Here is a link to the launchpad schematic: http://www.ti.com/tool/msp-exp430g2
  3. I've always had horrible luck with software. That's why I'm a hardware guy. Probably my only bet now is to buy two new complete launchpads and start from scratch. Still, I have to stress that the MOSI pin is behaving in exactly the same way the CSN pin should behave. Somehow, I think the pins got switched around in the code.
  4. Yes, the blinking works fine. Most recently, I removed the blinking and loaded the exact code from github. The brown and orange are in their correct locations. The picture can be misleading. Everything works exactly the same on the launchpad. Before, I was getting 1/2VCC on some of the pins such as CE, but I think that's because the LED was still connected. Now, I disconnected it. Adding a 0.1uF cap from VCC to GND does nothing. I make it common practice to put a cap from RST to ground though.
  5. Yes, I found that bug some time ago. At first, I must have tried reinstalling SPI before discovering the trick of moving it to the front of the code. Anyway, that's irrelevant, since I'm using Energia 17 now with the proper SPI file that came with it. Here is a photo with the corresponding pin wires below: Blue: GND and VCC Black: P2.0 Green: P2.1 Yellow: P1.5 Orange: P1.7 Brown: P1.6 Red: P2.2 47K from VCC to RST LED is included just for the receiver. A separate 330 ohm resistor is included to allow the power supply to drain faster.
  6. Well, it looks like I was using the SPI file provided by Energia, so that's not the problem. I find it interesting that the MOSI pin is behaving the way CSN should behave. Somewhere along the line, the pins must have been flipped in the software.
  7. I tried to edit my post to include a quote. Then, I just gave up and typed quotes around it! Hopefully everyone will catch my drift. Both versions meaning Energia 17 and Energia 18. As I type, I'm extracting the Energia 17 files to see if it already had the SPI file.
  8. When I downloaded both versions of Energia, the Tx/Rx codes would not compile until I downloaded SPI to the libraries. Of course, this is assuming my memory serves me right. Backing up a bit, I took the exact Tx code from github, loaded it on to both of my G2553's, and hooked them up to my two nRF24L01's. Same symptoms from both of them. So, either a piece of hardware is bad on both setups, or there's something wrong with the software. My guess is the software (meaning SPI). "SPI keeps the chip select pin high until it is ready to transmit and then pulls it low. It then returns to high following transmission." This is exactly what happens, only it's on the MOSI pin, not CSN.
  9. I don't know for sure if the receiver is actually working, but I do know that it is drawing a constant 14mA and the CE pin remains high. These IC's are from Mouser, which has had a problem in recent past with counterfeit parts, so new G2553's should be on order. I can try new nRF24L01's as well, but like I said, I mixed and matched different combinations of transceivers and IC's, all with the same result. I've also disconnected and reconnected the setup multiple times with the same result, so I'm fairly confident in the wiring. I'm using a 20A power supply which has plenty of capacitance at the output, so it should be able to adequately power the nRF24L01 to transmit a couple feet for testing purposes. "modules set on different channel or other incompatibility in way software is set up". This, I have not looked into and don't really know enough about it to check. By the process of elimination, I have been leaning toward the SPI file being at fault. Where is a good place to find a SPI file? I can't even remember where I downloaded mine.
  10. I did try switching the IC codes. Still, whichever chip the transmitter code is on, the CE pin will not go high and will not activate. Either chip will work fine with the receiver code. I also tried switching the nRF21L01's, but still could not isolate the problem to any specific piece of hardware. Should the CE pin be high on the transmitter? I noticed, during the short duration when it is transmitting a bit, the CE pin briefly pulses high, but only barely in the mV range. Also, the transmitter code is supposed to send two bits in the loop. This brief pulsing effect seems to happen when transmitting each bit. I know this because I added the flashing LED code to the end of the loop to indicate when it is cycling back to the beginning of the loop. I get two shorts pulses (One pulse: 3.3V to 0V and back to 3.3V on the MOSI pin) before the LED flashes. Then, it cycles back, emits 2 short pulses, flashes the LED, and so on. Here's the modified loop code: void loop () { Serial.print("Sending packet: "); Serial.println(str_on); radio.print(str_on); radio.flush(); // Pulsing on MOSI pin (3.3V to 0V and back to 3.3V) dump_radio_status_to_serialport(radio.radioState()); // Should report IDLE delay(1000); Serial.print("Sending packet: "); Serial.println(str_off); radio.print(str_off); radio.flush(); // Pulsing on MOSI pin (3.3V to 0V and back to 3.3V) dump_radio_status_to_serialport(radio.radioState()); // Should report IDLE delay(1000); int x = 0; while(x<15) { digitalWrite(P1_0, HIGH); // turn the LED on (HIGH is the voltage level) delay(100); // wait for a 1/10th second digitalWrite(P1_0, LOW); // turn the LED off by making the voltage LOW delay(100); // wait for 1/10th second x=x+1; } } By the way, I did try Energia 17 and 18 with the same results.
  11. Or possibly, the transmitter is only supposed to draw current during the short time when it transmits a bit? In that case, it is working correctly from an electrical perspective. However, the overall system doesn't work. There is no response from the receiver. Being completely new to all of this, I don't know where to take it from here?
  12. For weeks now, I have been trying to interface my MSP430G2553's with nRF24l01 transceivers. The sample code for the receiver seems to be working alright. I was able to measure the pin voltages and monitor the current draw of the receiver. However, the transmitter doesn't seem to be working as expected. The CE pin will not go high. Even if I force it high, the transmitter will not draw any current. The only thing I did to change the code was to add a few lines for a flashing LED. This is to ensure that the microcontroller is active when used as a standalone. Here's the code: #include <SPI.h> #include <Enrf24.h> #include <nRF24L01.h> #include <string.h> Enrf24 radio(P2_0, P2_1, P2_2); // P2.0=CE, P2.1=CSN, P2.2=IRQ const uint8_t txaddr[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0x01 }; const char *str_on = "ON"; const char *str_off = "OFF"; void dump_radio_status_to_serialport(uint8_t); void setup() { Serial.begin(9600); SPI.begin(); SPI.setDataMode(SPI_MODE0); SPI.setBitOrder(MSBFIRST); radio.begin(); // Defaults 1Mbps, channel 0, max TX power dump_radio_status_to_serialport(radio.radioState()); radio.setTXaddress((void*)txaddr); //MY ADDITION TO THE CODE (FLASHING LED). THIS ENSURES THE MICROCONTROLLER IS READY/ACTIVE. pinMode(P1_0, OUTPUT); digitalWrite(P1_0, LOW); int x=0; volatile int state = HIGH; volatile int flag = HIGH; digitalWrite(P1_0, state); while(x<15) { digitalWrite(P1_0, HIGH); // turn the LED on (HIGH is the voltage level) delay(100); // wait for a 1/10th second digitalWrite(P1_0, LOW); // turn the LED off by making the voltage LOW delay(100); // wait for 1/10th second x=x+1; } //END FLASHING LED } void loop() { Serial.print("Sending packet: "); Serial.println(str_on); radio.print(str_on); radio.flush(); // Force transmit (don't wait for any more data) dump_radio_status_to_serialport(radio.radioState()); // Should report IDLE delay(1000); Serial.print("Sending packet: "); Serial.println(str_off); radio.print(str_off); radio.flush(); // dump_radio_status_to_serialport(radio.radioState()); // Should report IDLE delay(1000); } void dump_radio_status_to_serialport(uint8_t status) { Serial.print("Enrf24 radio transceiver status: "); switch (status) { case ENRF24_STATE_NOTPRESENT: Serial.println("NO TRANSCEIVER PRESENT"); break; case ENRF24_STATE_DEEPSLEEP: Serial.println("DEEP SLEEP <1uA power consumption"); break; case ENRF24_STATE_IDLE: Serial.println("IDLE module powered up w/ oscillators running"); break; case ENRF24_STATE_PTX: Serial.println("Actively Transmitting"); break; case ENRF24_STATE_PRX: Serial.println("Receive Mode"); break; default: Serial.println("UNKNOWN STATUS CODE"); } } Eliminating the flashing LED doesn't solve the problem. Other symptoms vary depending on if the IC is on the launchpad or standalone. On the launchpad, the CE and MISO pin remain at about half supply voltage. Standalone, they remain low. The most significant observation (only happens for standalone) is that the MOSI pin stays at 3.3V as expected, but pulses toward 0V every second or so repeatedly. During this short pulse duration, the transceiver tries to draw some current, but then shuts off immediately. The CE pin remains low for the most part. However, I was able to get a measurable voltage (in the mV range) during this odd pulse time. If I am correct in my assumptions, hardware setup remains the same between receiver and transmitter. Any help here would be greatly appreciated.