bitknitting

~ Stuff I Learned About Tech+Hydroponics

bitknitting

Category Archives: 802.11

Debugging the SPI Bus – When Components Won’t Share

02 Monday Dec 2013

Posted by bitknitting in 802.11, Arduino, cc3000, debugging, Home Network, New Category, RFM12B

≈ 2 Comments

Tags

debugging, SPI

Update 3/2/2015: Bil Herd put out a video on digital POTs.  He explains I2C and SPI at this point in the video.

Update 11/26/2014:  I just finished reading an excellent article: “Better SPI Design in 3 Steps” that is a must read when working with multiple devices sharing the SPI bus.

 

As I got into building the Base System, the SPI bus was used by many of the components.  I had a conceptual view of how the SPI bus worked, after all, it is well described in wikipedia.  

However, I didn’t have a working knowledge.  This concerned me because I was running into “traffic jams”.  In my case, once I initialized the cc3000, the RFM12B could no longer communicate on the SPI bus.

It became frustrating and concerning to not know if I purchased a component that needed to share the SPI bus if indeed it was a good citizen.  This was turning out to mean more than being able to set the CS/SS pin.

I decided to take a step back and try to figure out why there is this failure to share the SPI bus.  It is an OPPORTUNITY TO LEARN!  Since learning is in many ways what gets me up too early each day, I was eager to get to know the details of this all important data transfer bus. 

Peeking into SPI Bus Traffic with a Logic Analyzer

In order to gain a deeper understanding of SPI bus communications, the first thing I did was order the Saleae Logic Analyzer from Adafruit.  I had no clue how to use this…and it wasn’t until I talked to Mark – the incredibly helpful support person at Saleae – who patiently stepped me through using the logic analyzer – as well as watched their “how to” video did it all make sense.  I’ve done phone support at both Microsoft and Sabi.  It is a very hard job.  Especially helping over the phone.  I was very impressed with Mark’s patience in what I thought was my hideously “duh” questions.    A lot of that loyalty comes from how the product is supported.

Steps to debug:

  • wire RFM12B and cc3000 to the Arduino
  • add logic analyzer wires to the four SPI channels.  
  • start the logic analyzer software and load the SPI profile (for both the RFM12B and cc3000).
  • capture and analyze the SPI channels when the config information is displayed

Setting up the Logic Analyzer

I’ll be using all eight lines of the logic analyzer.  Four for the cc3000’s SPI traffic and four for the RFM12B’s traffic:

ArduinoWithLogicAnalyzer

yet another snarly mess of wires. 

Basic SPI Traffic

Nick Gammon has an excellent post on interpreting the squiggles of the Logic Analyzer.  Reading this post gave me a great start at how the SPI lines are used and interpreted.  How terrific to find this resource and that Nick shared his knowledge in such a clear/understandable way.  THANK YOU NICK!!!!

As a sanity check, I started by analyzing the traffic generated by the RFM12B and then the cc3000.

Simple RFM12B SPI Traffic

To get a feel for the SPI bus traffic, I captured traffic that occurs when the function rf12_config() is called.  

The sketch (note: I am using pin 9 for the CS/SS pin):

#include <RF12.h>
void setup()
{
rf12_set_cs(9);
rf12_config(true);
}
void loop()
{
}

This image shows the start of the traffic: 

LogicStartrf12_config

 

Notice the traffic occurs on the lines connected to the RFM12B.  The Arduino is sending bytes to the RFM12B (MOSI). The RFM12B’s CS pin is taken low to enable it.  The cc3000’s CS remains high.  Once the two bytes are read by the RFM12B, the RFM12B takes the CS high to note the end of sending/receiving data.

One “gotcha” using this Logic Analyzer:  On the plus side it supports the Mac.  On the more challenging UI side is the UI to find the MOSI and MISO transfers and then zoom into them.  To find the MISO and MOSI transfers, I find I have to zoom out to a timeline that shows increments in seconds.  To read the hex values, I then need to zoom into the MOSI or MISO line.  Zooming in is best done by clicking on the line until the timeline expands to show the hex values (microsecond increments).  I can also go to new readings with the N or P (for Next and Previous) keys.  However, I lose context of where I am.  While I have become very used to a trackpad I found I must use a mouse to navigate.

The Logic Analyzer provides a way to export the readings into a CSV file.  This made it far easier to sanity check reading SPI traffic.

Looking at the code in RF12.cpp,rf12_config() calls rf12_initialize().  The code that transfers bytes over the SPI from the Arduino to the RFM12B is listed on the left side of the table below.  Note the bytes on the right side correspond to the code.  For example, RF_SLEEP_MODE is #define’d earlier in RF12.cpp to be  0x8205 and  RF_TXREG_WRITE is #define’d to be 0xB800

   rf12_xfer(0x0000); // intitial SPI transfer added to avoid power-up problem

   rf12_xfer(RF_SLEEP_MODE); // DC (disable clk pin), enable lbd

   

   // wait until RFM12B is out of power-up reset, this takes several *seconds*

   rf12_xfer(RF_TXREG_WRITE); // in case we’re still in OOK mode

   while (digitalRead(RFM_IRQ) == 0)

       rf12_xfer(0x0000);

       

   rf12_xfer(0x80C7 | (band << 4)); // EL (ena TX), EF (ena RX FIFO), 12.0pF

   rf12_xfer(0xA640); // 868MHz

   rf12_xfer(0xC606); // approx 49.2 Kbps, i.e. 10000/29/(1+6) Kbps

   rf12_xfer(0x94A2); // VDI,FAST,134kHz,0dBm,-91dBm

   rf12_xfer(0xC2AC); // AL,!ml,DIG,DQD4

   if (group != 0) {

       rf12_xfer(0xCA83); // FIFO8,2-SYNC,!ff,DR

       rf12_xfer(0xCE00 | group); // SYNC=2DXX;

   } else {

       rf12_xfer(0xCA8B); // FIFO8,1-SYNC,!ff,DR

       rf12_xfer(0xCE2D); // SYNC=2D;

   }

   rf12_xfer(0xC483); // @PWR,NO RSTRIC,!st,!fi,OE,EN

   rf12_xfer(0x9850); // !mp,90kHz,MAX OUT

   rf12_xfer(0xCC77); // OB1,OB0, LPX,!ddy,DDIT,BW0

   rf12_xfer(0xE000); // NOT USE

   rf12_xfer(0xC800); // NOT USE

   rf12_xfer(0xC049); // 1.66MHz,3.1V

*

A tool that can help with understanding RFM12B Commands is this  RFM12B Command Calculator.

A Taste of cc3000 SPI Traffic

In my last go around attempting to have the RFM12B and cc3000 boards share the SPI bus, the traffic jam occurred after the call to cc3000.begin().  After that, the RFM12B was not able to transfer data on the SPI bus.  So the taste of SPI traffic I’m interested happens in cc3000.begin()…what state is the SPI bus left in that shoves the RFM12B out of sending/receiving over the MISO and MOSI lines?

Here is the sketch I am using:

#include <Adafruit_CC3000.h>
#include <ccspi.h>
#include <SPI.h>

#define ADAFRUIT_CC3000_IRQ 3 // MUST be an interrupt pin!
// These can be any two pins
#define ADAFRUIT_CC3000_VBAT 5
#define ADAFRUIT_CC3000_CS 8
// Use hardware SPI for the remaining pins
// On an UNO, SCK = 13, MISO = 12, and MOSI = 11
Adafruit_CC3000 cc3000 = Adafruit_CC3000(ADAFRUIT_CC3000_CS, ADAFRUIT_CC3000_IRQ, ADAFRUIT_CC3000_VBAT,
SPI_CLOCK_DIV2); // you can
void setup()
{
Serial.begin(57600);
if (cc3000.begin())Serial.println(“Initialized the cc3000”);
else Serial.println(“Did NOT initialize the cc3000”);
}
void loop()
{
}

I ran this sketch while capturing its SPI bus traffic through the Logic Analyzer.

First, a zoom in on a few bits of initial cc30000.  

cc3000SPITraffic 

I note two differences in how the cc3000 transfers bits:

  • Note the clock line for the cc3000.  Unlike the RFM12B – where data is sampled when the clock is going low to high on the leading edge, data is sampled when the clock is going from high to low on the trailing edge. Nick Gammon’s post does a great job explaining the SPI “data modes”.  I also thought a post on Sparkfun did a nice job :

The slave will read the data on either the rising edge or the falling edge of the clock pulse. Additionally, the clock can be considered “idle” when it is high or low. In the Arduino SPI library, both of these options are controlled by the setDataMode() function.

  • Sampling occurs at a faster rate than it does for the RFM12B. Back to the Sparkfun post for an explantation on sample rates:

SPI can operate at extremely high speeds (millions of bytes per second), which may be too fast for some devices. To accommodate such devices, you can adjust the data rate. In the Arduino SPI library, the speed is set by the setClockDivider() function, which divides the master clock (16MHz on most Arduinos) down to a frequency between 8MHz (/2) and 125kHz (/128).

When the RFM12B Stops Talking

if I run a sketch that initializes the cc3000 using the cc3000.begin() function and then run rf12_config(), something has changed with the MISO line.  Contrast the MISO line readings below with the readings I showed earlier:

Time [s] Packet ID MOSI MISO
4.39353675 0 0x00 0xFF
4.39354125 0 0x00 0xFF
4.393549 1 0x82 0xFF
4.3935535 1 0x05 0xFF
4.39356125 2 0xB8 0xFF
4.39356575 2 0x00 0xFF

All MISO readings are 0xFF.  This was noted by Martyn in a thread on the JeeLabs forum where I asked for help on what was going on:

It [the MISO line] is stuck high after the cc3000.begin(). Since the SPI bus is inverted logic, that maps to the FF (falsely) decoded. 

Once cc3000.begin() has been executed, the RFM12B is unable to communicate over the MISO.  As Martyn noted:

  • The breakout board level converter sees the 3V high as an input and drives a 5V high hard independent of CC3000 selected
  • The poor RFM12B working at 3V through a resistor divider doesn’t stand a chance to pull this signal down.

An answer on the Adafruit forum gave me pretty much the equivalent information.   

the breakout version of the cc3000 needs something to buffer MISO as it is not tristated

http://learn.adafruit.com/adafruit-cc30 … 

you can look at the cc3000+SD exam.ple sketches for how to share the SPI lines, but no, the CC3000 does not work great with other SPI devices without a lot of care & debugging. this kind of stuff is not easy to fix, if you’re “new to electronics”, you may find this project challenging and we don’t offer coding or library modification support and assistance.our suggestion is to find an RF module that does not require sharing those pins.

At the time I read the replay on the Adafruit forum, I was more or less flailing like a fish on the deck of a boat in my understanding of what was being said.  My  lack of understanding is what compelled me to at least gain a better understanding of the SPI bus and perhaps the challenge of fixing this challenge.  Alsom I got a little thrown with some of the reply:

  • what does buffer MISO mean?  I get that the cc3000 leaves the MISO stuck high (see Martyn’s comment below).  Perhaps it just means bytes sent by the cc3000 over the MISO line?
  • the suggestion to look at the example sketches.  This made sense if it was a conflict with the CS pin.  However, I’m using different CS pins.  The challenge is in the state of the MISO after cc3000.begin() is called.  Of more interest is the schematic of the cc3000 Shield, which uses the 74AHC125 to tri-state the MISO pin.

 Oleg Mazurov sums up the issue in his post on the SPI bus:

Only one device, the one whose SS line is asserted low, is participating in the transfer by driving its MISO line – all other devices are expected to have their MISO line in a third state.

Can the cc3000 and RFM12B Co-Exist in a Circuit?

A Software Fix

Given my background is in software, the easiest solution I can think of was a software solution.  

1) initialize the cc3000 with cc3000.begin();

2) call wlan_stop()

(see wlan.cpp: Stop WLAN device by putting it into reset state.)

3) when switching RF traffic, wrap the cc3000 calls with wlan_start(0) and wlan_stop()

Here is some snippet of a sketch that does this:

//initialize the cc3000 then stop it to allow RFM12B to use the MISO line

if (cc3000.begin())Serial.println(“Initialized the cc3000”);
else Serial.println(“Did NOT initialize the cc3000”);
wlan_stop();
Serial.println(“cc3000 stopped”);

//nitialize the rrm23b

rf12_set_cs(9);
rf12_config();

//do wiFi traffic

Serial.println(“Start cc3000”);
wlan_start(0);
if (!cc3000.connectToAP(WLAN_SSID, WLAN_PASS, WLAN_SECURITY)) {
Serial.println(F(“Failed!”));
while(1);
}
Serial.println(F(“Connected!”));
/* Wait for DHCP to complete */
Serial.println(F(“Request DHCP”));
while (!cc3000.checkDHCP())
{
delay(100); // ToDo: Insert a DHCP timeout!
}

/* Try looking up http://www.adafruit.com */
// uint32_t ip = 0;
Serial.print(F(“www.adafruit.com -> “));
while (ip == 0) {
if (! cc3000.getHostByName(“www.adafruit.com”, &ip)) {
Serial.println(F(“Couldn’t resolve!”));
}
delay(500);
}
cc3000.printIPdotsRev(ip);
//
// /* Do a quick ping test on adafruit.com */
Serial.print(F(“\n\rPinging “));
cc3000.printIPdotsRev(ip);
Serial.print(“…”);
replies = cc3000.ping(ip, 5);
Serial.print(replies);
Serial.println(F(” replies”));
if (replies)
     Serial.println(F(“Ping successful!”));
Serial.println(“stopping cc3000”);
wlan_stop();
Serial.println(“cc3000 stopped”);

//send traffic back and forth between RFM12B nodes and the Base System…

A Hardware Fix

I have stumbled into the 5V – 3.3V clash of the Arduino and breakout boards.  As noted in this SparkFun learning post on voltage dividers (see the section on Level Shifters):

Many of those sensors operate at a relatively low voltage, in order to conserve power. Unfortunately, it’s not uncommon that those low-voltage sensors are ultimately interfacing with a microcontroller operating at a higher system voltage. This leads to a problem of level shifting, which has a number of solutions including voltage dividing.

Recall what Martyn said:

  • The breakout board level converter sees the 3V high as an input and drives a 5V high hard independent of CC3000 selected
  • The poor RFM12B working at 3V through a resistor divider doesn’t stand a chance to pull this signal down.

 While I haven’t tried it, I read this to mean I would need to shift the 5v high to a 3.3V so that the RFM12B could pull the MISO line down.  This would be done by a level shifter – which as the cc3000 breakout board and shield schematics show are needed to shift between the 5v of the Arduino’s i/o to the 3.3v of the chip’s.

In my quest to learn, I will try this.  And YIPPEE!! I will be aided by the BitScope 10 oscilloscope I anxiously await to receive in the mail!  Too bad the Logic Analyzer doesn’t support a scope mode.  If I make progress with using a level shifter to solve the cc3000 sharing the MISO line with the RFM12B I’ll let you know through a new post.

Finally

I think I found a workaround.  In the process, I learned a lot about using a logic analyzer and SPI traffic.  As usual, folks on forums were kind in sharing their knowledge – giving insightful and actionable advice.  It is a great feeling to have a better understanding of why a circuit is not working.  I found learning how the logic analyzer can debug in serial communications to be valuable and will certainly come in handy as I continue my quest to build a hydroponics sensor network.  I’m a long way off from a never ending supply of vegetables to feed my family, but I feel one step closer in my ability to build the system.

Advertisements

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Google
  • Email
  • Pinterest

Like this:

Like Loading...

Better Together? Arduino Uno+SD Shield+cc3000+RFM12B

14 Thursday Nov 2013

Posted by bitknitting in 802.11, cc3000, RFM12B, sensors, Wireless Communication Between Sensors

≈ 2 Comments

Tags

Base System, hydroponics, Sensor Data, wireless

In the last post on the hydroponics sensor network, I detailed using a JeeNode as the wireless micro controller from which sensors would be connected.  Previous to that, I discussed the beginnings of a Base System that was based on an nRF24L01 wireless between a sensor node (not a JeeNode at the time) and Adafruit’s cc3000 (802.11) breakout board. 

I am calling the hardware and software that receives the sensor data – eventually from a number of sensor nodes that are monitoring and applying action from hydroponics systems throughout my house – the Base System.  I am still exploring what hardware features to include.  In this blog post, I am exploring a Base System that uses an Arduino Uno, JeeLab’s RFM12B board to receive data from a JeeNode, Adafruit’s cc3000 breakout board to send the data to an Internet service, and Adafruit’s SD Shield to keep a local store of the sensor data.

Goals

The goals of this post include:

  • Wiring up the components into a circuit that receives data from a JeeNode.
  • Discuss lessons learned.  Fortunately – or unfortunately if you have “been there, done that” since I fear my write up of these will bore you – there are plenty lessons learned since this is the first time I have put these separate components together under one Sketch.
  • Detail two areas of concern: 1) The amount of SRAM gobbled up by each component and 2) How well the components cooperate sending and receiving data over the Arduino’s SPI bus.

Challenges

The third goal makes special note of two areas of concern.  On the one hand, it is amazing how many libraries exist for all these components that “plug and play” with an Arduino.  On the other hand, there is no quality control on the libraries.  There is no mandate that says minimize the amount of SRAM used – even though SRAM on an Arduino is a very constrained resource.  There is no hardware compatibility assurances that make best efforts for components that share a bus to play well together.

For an example of hardware compatibly, take the use of the SPI bus.  A challenge with the SPI bus is summarized as a bullet point under “Disadvantages” in the SPI Wikipedia entry:

Without a formal standard, validating conformance is not possible

Wouldn’t it be great if there was a test harness for components that use the SPI device as there are for devices that are plopped into many operating systems?  Well, there isn’t. 

Steps 

The steps I’m going to take include:

  • Determine the SRAM memory footprint of each of the components to see how much of the 2K SRAM the ATmega 328p has that is being taken up.
  • Replace the JeeLink with the RFM12B board  since the JeeLink is not extensible.
  • Isolate each component with the Arduino and run the component’s “hello world” sketch.
  • Add each component to the Arduino Uno.  As each component is added, run their respective “hello world” sketch that comes with the supporting library.
  • Test if the devices “play well with others”  when they access the SPI bus. 

Amount of SRAM

Before we dive into the components, I wanted to share what I found out about determining the all important amount of available SRAM.

JeeLabs has an excellent post on measuring an ATmega’s memory use.  In addition, the Arduino memory tutorial also has some useful information. His post includes a function that will let me know how much SRAM is being taken up when a component is added.  This will give me an idea if (more likely when!) I will need an ATmega with more SRAM:

int freeRam () {

extern int __heap_start, *__brkval; 
int v; 
return (int) &v – (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

I find the above type of functions clever.  Look at this image
ATMega Memory
and note how the freeRam() function uses the address of v – the last variable put on the stack – to determine the gray area (i.e.: available memory) between the heap and the stack by subtracting the address of the top of the heap from the address of the top of the stack.  

The post also gives additional insight:

all C strings are also stored in SRAM! This explains why adding a single character to the string reduced available memory.

Luckily, the Arduino IDE provides a way to stick strings in Flash – of which the AtMega328P has 32KB:

You can pass flash-memory based strings to Serial.print() by wrapping them with F(). For example: Serial.print(F(“Hello World”));

So to minimize the memory use, I put all Serial.print[ln] strings inside an F().

Another thing the IDE lets me do is to store variables in Flash instead of SRAM.  For example, the line char payload[] = “Hello!”; can be put into Flash memory by using the prog_char typedef.  to prog_char payload[] = hello!”;  My thought was every little bit of SRAM counts.  But ultimately, the ATmega 328p will most likely run out of 1K or more of needed memory.  It does seem like good practice until someone with more experience tells me why doing so is a bad idea.

I’ll be using:
  • freeRam()
  • wrapping Serial.print[ln] strings inside an F()
  • storing variables into Flash memory
As I check the amount of SRAM used by each component’s libraries.

Amount of available SRAM

I wanted to follow up on a comment made by Matt:

“… the ATMEGA 328P only has 2K SRAM and if you intend to use SD cards, ethercards and wireless cards in your system, you might find this a limiting factor. You might want to look at maybe using something like an ATMEGA 1284P based system.”

Given the small amount of SRAM, Matt’s concerns are definitely valid.  But do I immediately need to the ATmega 1284P?

Here’s the additional amount of SRAM used by the component’s libraries:

 

bytes

prior to adding components

209

Adafruit’s SD Shield

693

RFM12B board

100

cc3000

590

Total

1592


After the components are piled on, I was left with 456 bytes. A tight fit! I will most likely change fairly soon to an ATmega with more SRAM.

 
Now it’s time to get the components to work.

Testing Each Component

Adafruit’s Data Logging Shield

I got the Data Logging Shield and shield stacking headers for an Arduino Uno from Adafruit.com.  For the SD card I found an old one that was lying around the house used in a now obsolete digital camera many years ago. 

Solder the Headers

I found this post by freetronics to give helpful hints on the best way to solder shield stacking headers onto a shield.

SD Shield Showing Solder Job

I was happy to see that my soldering skills have improved a bit.

Testing the Data Logging Shield

The libraries I used to test the shield included:

  • Adafruit’s SD Library
  • RTC Library

I followed Adafruit’s tutorial to test and become familiar with the shield.  There was a lot at the beginning of the tutorial I ignored because I am using an Uno and these sections were for other Arduino variants.The first thing is to try out the RTC (Real Time Clock).  This was easy and worked great.  It was exciting to read:

 For the RTC library, we’ll be using a fork of JeeLab’s excellent RTC library

within the tutorial.  I truly appreciate the great works that we build upon!  

The tutorial recommends formatting the SD.  This was easy enough using this formatter:

Download the formatter from https://www.sdcard.org/downloads/formatter_4/

I then ran the CardInfo.ino sketch which came with Adafruit’s SD library.  

Yippee!  Here’s what I got on the serial monitor:

______________________________________________________________________

Initializing SD card…
Card type: SDHC

Volume type is FAT32

Volume size (bytes): 3644850176
Volume size (Kbytes): 3559424
Volume size (Mbytes): 3476

Files found on the card (name, date and size in bytes

______________________________________________________________________

The first two times I ran CardInfo.ino, I was guilty of two checks noted below: 1) I didn’t insert the SD card 2) I had left the SPI chip select to 4.  I needed to set it to 10.  I found this initial check in the sketch helpful.  Taking debugging one more step, I wish all libraries were capable of providing APIs that debugged more deeply at each level.  During my stint at Microsoft, we realized the layers of interdependency at both the hardware and software level.  A lot of attention was put into making sure the various network stacks (e.g.: TCP/IP, security) had debugging output. It gets extremely time consuming to track down challenges without that.  I feel this is an area where these open source libraries and break out boards could help save us a lot of time.  However, I doubt it will sell more breakout boards.  Plus, I doubt the breakout boards are put in positions that could bring a Fortune 50 company’s network down.   So I can see why the extra effort is not applied to detailed testing and debugging.  

I found CardInfo’s “what might be wrong checklist” to be extremely helpful in debugging the most obvious reasons why the SD card is not read.

______________________________________________________________________

Initializing SD card…initialization failed. Things to check:
* is a card is inserted?
* Is your wiring correct?
* did you change the chipSelect pin to match your shield or module?

______________________________________________________________________

JeeLab’s RFM12B Board

Since the JeeLink does not support adding on additional components, I purchased JeeLab’s RFM12B Board Kit so RFM12B can be added to an Arduino through the SPI bus.  This will allow the base station to gather sensor readings from the JeeNode that was built in this post.

RFM12B Board Kit

The kit comes with all the goodies that need to be soldered together before the breakout board can be attached to an Arduino.  I used the info in this PDF to figure out where/how the resistors, capacitors, antenna, and RFM12B chip should be soldered.

Here is the breakout board after I soldered it together.


 
RFM12B FrontSide
 RFM12B BackSide
 
Clearly my soldering skills need improvement.   I like the way the board has made it easy to remember which pin of the board needs to be wired to which pin on the Arduino (note the D13 above SCK/D12 above SD0, etc.).  I outlined two other boxes which turned out to be trouble spots.  I’ll cover these later.

Can You Hear Me?

Time to test out the RFM12B sending and receiving packets to the JeeNode.  For this test, I uploaded the RF12Demo.ino sketch that is found within the RF12 Examples that come with the JeeLib library onto both the RFM12B board and JeeNode.  The RF12Demo sketch is great for getting a feel for how well communications are working between nodes.  
 
BUMMER…. 😦 ….The RFM12B board did not work.   A Challenge!  Why, why, why?
 
I wrote out how I eventually got the board working because I see debugging as a key part of the process of coming to something that actually works in real life – not just on paper.  Debugging is an amazing learning opportunity.

TroubleShooting

Here is what I get after using the AppleScript to set up two terminal sessions (and changing the serial ports to match those used by the RFM12B and JeeNode)
 
 
RF12Demo First Try
The screen shot is a bit hard to read – on the left is the JeeNode (serial port AE01DTYI).  On the right is the RFM12B board (serial port USBMODEMFD111).  I use the ‘t’ command to (as the help notes) “broadcast max-size test packet, request ack.”).  The JeeNode (left) is working.  But the RF12B board is not.   So I do what I normally do in my troubleshooting process: 1) self-doubt: “gee – the chances of me getting this working is small.  Should I just get another one?” 2) review the RF12Demo.ino sketch and the RF12.cpp library. 3) make sure communications settings are correct.  Are they both at the same frequency?  Are they in the same group?  What are the values for the node?  Originally the RFM12B board was on node 1, group 212, and sending/receiving data at a frequency of 433MHz.  Compare this to the JeeNode which was set at node 31, group 100, 868 MHz frequency.   
 

First Change

The first change I made was to set the node/group/frequency of the RFM12B board.  The RF12Demo.ino supports the serial input commands that are displayed when the ‘?’ command is enterred.  Entering 8b changes the frequency to 868MHz.  Entering 100g changes the group to 100.  Entering 31i changes the node to 31.  
 
Note: from the JeeLab FAQ:

Node ID’s should be unique within the netGroup in which this node is operating. ID 31 is special because it will pick up packets for any node (in the same netGroup). ID 0 is also special, it is used to transmit in a special “OOK” format.

In the future I will use different node id’s between 1 and 30.
 
Did it work?
 
Try again with the settings showing both nodes on the same frequency, within the same group, and on node 31.  Nope…still doesn’t work.
 

Second Change

My next step was to check the wiring.  Was GND and + and SPI pins all connected correctly?

Arduino And RFM12B

Always a good thing to check!  This time I seemed to have wired the pins correctly.

My next step is to cry for help on the JeeLabs support forum.  Once again, the members of this forum are incredibly helpful.  I have also found them to give insightful guidance.

Plutonomore recommended changing the 3v3 connection to 5v.  I did, but I should be able to use either since there is a connecting pin for either 3v3 or 5v (see the image above).

 RE: Trouble Shooting RFM12B Board Kit? – Added by plutonomore 1 day ago

It also just occurred to me that you are using an Arduino, therefore 5V, not a JeeNode 3V3.
Therefore try the previously suggested wiring setup but change the 3V3 connections on both
boards to 5V. Also you will need to have the 3x 4k7 and 3x10k ohm voltage divider resistors

cheers,

Comment
                                  

 JohnO noted the DATAFLASH #define (I agree that my soldering needs practice!).  It turns out the JeeLink and JeeNode have a data flash chip that is used for data logging.  So I took JohnO’s advice and set #define DATAFLASH 0 from #define DATAFLASH 1.  I saved the sketch with this change to RF12DemoUno.ino since now the JeeNode and Arduino UNO + RFM12B are different.  But I am not sure why data logging would get in the way of transmitting and receiving data…

 RE: Trouble Shooting RFM12B Board Kit? – Added by JohnO about 5 hours ago

Your soldering isn’t too bad although Rohan will be appalled – Rohan is Martyn’s son and a wiz with a soldering station.  

If you are happy to, can I ask that you load the RF12Demo while only changing “#define DATAFLASH 0”. With a terminal session connected to both running versions of RF12Demo and capturing output. Then press the ‘?’ once on each and follow up with a second or two of ‘t’ command. Then post the two output files that you captured.

 Did it work?
 Try again with these changes….Nope…still doesn’t work.
 

Third Change

 I had sent a reply that included the images above to show my soldering efforts.  It is not clear to me how to debug which resistor, capicitor, or other component I soldered is not working.  
And then a YIPPEE!!!! Moment when Martynj noted:

 RE: Trouble Shooting RFM12B Board Kit? – Added by martynj about 5 hours ago

Hmmm.. a couple of “dry” joints visible but more significantly, ANT // Vdd on the RFM12B module appear shorted. Worth a touch up with solder braid, but may prove to be terminal.

Take a look at the front and back of the RFM12B images above, focusing on the areas that have the red rectangle on them.  I used solder remover to get rid of excess solder around the antenna.  And then put more solder on pin on the back side of the board.

Solder Remover

I then cleaned off the flux using the inexpensive technique noted in this youtube video.  This technique seemed to work well.

Here is the front and the back of the RFM12B after removing solder around the antenna and adding solder to one of the pins for a resistor:

 Solder Off Ant  SolderOnResistor

 Did it work?

YIPPEE!  This worked. I was surprised.  I assumed I’d muffed up the soldering beyond repair.  Luckily, I had not.


JeeNode

Arduino Uno + RFM12B Board

[RF12demo.10] _ i31 g100 @ 868 MHz

Available commands:

 <nn> i     – set node ID (standard node ids are 1..30)

 <n> b      – set MHz band (4 = 433, 8 = 868, 9 = 915)

 <nnn> g    – set network group (RFM12 only allows 212, 0 = any)

 <n> c      – set collect mode (advanced, normally 0)

 t          – broadcast max-size test packet, request ack

 …,<nn> a – send data packet to node <nn>, request ack

 …,<nn> s – send data packet to node <nn>, no ack

 <n> l      – turn activity LED on PB1 on or off

 <n> q      – set quiet mode (1 = don’t report bad packets)

 <n> x      – set reporting format (0 = decimal, 1 = hex)

 123 z      – total power down, needs a reset to start up again

Remote control commands:

 <hchi>,<hclo>,<addr>,<cmd> f     – FS20 command (868 MHz)

 <addr>,<dev>,<on> k              – KAKU command (433 MHz)

Current configuration:

_ i31 g100 @ 868 MHz

OK 63 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

-> ack

OK 63 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

-> ack

> 0t

test 0

-> 66 b

OK 223

> 0t

test 1

-> 66 b

OK 223

[RF12demo.10] _ i31 g100 @ 868 MHz

Available commands:

 <nn> i     – set node ID (standard node ids are 1..30)

 <n> b      – set MHz band (4 = 433, 8 = 868, 9 = 915)

 <nnn> g    – set network group (RFM12 only allows 212, 0 = any)

 <n> c      – set collect mode (advanced, normally 0)

 t          – broadcast max-size test packet, request ack

 …,<nn> a – send data packet to node <nn>, request ack

 …,<nn> s – send data packet to node <nn>, no ack

 <n> l      – turn activity LED on PB1 on or off

 <n> q      – set quiet mode (1 = don’t report bad packets)

 <n> x      – set reporting format (0 = decimal, 1 = hex)

 123 z      – total power down, needs a reset to start up again

Remote control commands:

 <hchi>,<hclo>,<addr>,<cmd> f     – FS20 command (868 MHz)

 <addr>,<dev>,<on> k              – KAKU command (433 MHz)

Current configuration:

_ i31 g100 @ 868 MHz

> 0t

test 0

-> 66 b

OK 223

> 0t

test 1

-> 66 b

OK 223

OK 63 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

-> ack

OK 63 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

-> ack

 
The commands I typed in don’t show up.  But it is easy to walk through.  The cell on the right represents the serial output of the sketch running on the Arduino Uno + RFM12B Board.  The cell on the right is output from the JeeNode.  I typed t as input to the sketch running on the Arduino Uno..  This wrote “>0t ->66 b OK 223” out to the serial port from the sketch running on the Arduino Uno.  On the left, the JeeNode received the data.  The sketch on the JeeNode wrote “OK 63 0 1 2 3 4 5….” to the serial port.  I type t twice to the Arduino Uno and twice to the JeeNode.
 
One more YIPPEE! because it was an amazing experience to “fix” this challenge!
 

Adafruit’s cc3000 Breakout Board

I’ve gone through testing the cc3000 in a previous post, so I won’t repeat the process here. 

Better Together?

Add the RFM12B to the Data Logging Shield

Time to find out if the RFM12B can ping/pong within the same sketch the SD Shield is spewing out info about the SD card.  This will test how well the components share the SPI bus.

Here’s where I ran into my first challenge.  Both the SD shield and the RFM12B board used pin 10 for the SPI CS (Chip Select).  Luckily, the RFM12B’s library has been enhanced to include rf12_set_cs() .   I set the CS pin for the RFM12B board to 9.  Although this solves my challenge of using two different pins for the two SPI CS pins, I was curious how easy it was to change the CS pin used by the SD Shield.  I asked how to do this on the Adafruit forum.  Here’s the answer I got.

Postby adafruit_support_bill » 08 Nov 2013 17:58

Yes. You can cut the trace between pin 10 and the adjacent breakout hole. Then you can run a jumper from the hole labeled “CS” to any other pin.

Image

 I didn’t try this – but good to know….

 

Sketch for JeeNode

Here is the sketch I downloaded onto the JeeNode:

 

#include <JeeLib.h>

 

MilliTimer sendTimer;

prog_char  payload[] = “Hello!”;

//char  payload[] = “Hello!”;

 

void setup () {

  Serial.begin(57600);

  rf12_initialize(2, RF12_915MHZ, 33);

}

void loop () {

  if (rf12_recvDone() && rf12_crc == 0) {

    Serial.println(F(“Receive data”));

    for (byte i = 0; i < rf12_len; ++i)

      Serial.print(rf12_data[i]);

    Serial.println();

  }

  if (sendTimer.poll(3000) && rf12_canSend()) {

    Serial.println(F(“Send data”));

    rf12_sendStart(0, payload, sizeof payload);

  }

}

Sketch for Base System

Note within this sketch:

  • The RFM12B CS pin is set to 9 right before the call to rf12_initialize().
  • The SD Shield library and pieces of the CardInfo sketch have been added so that data will have to flow between the components and the Arduino.

#include <JeeLib.h>

 // include the SD library:

#include <SPI.h>

#include <SD.h>

// set up variables using the SD utility library functions:

Sd2Card card;

SdVolume volume;

SdFile root;

// change this to match your SD shield or module;

const int chipSelect = 10;   

 

MilliTimer sendTimer;

prog_char  payload[] = “Hello!”;

//char  payload[] = “Hello!”;

 

void setup () {

  Serial.begin(57600);

  rf12_set_cs(9);

  rf12_initialize(1, RF12_915MHZ, 33);

   pinMode(SS, OUTPUT);

  // we’ll use the initialization code from the utility libraries

  // since we’re just testing if the card is working!

  while (!card.init(SPI_HALF_SPEED, chipSelect)) {

    Serial.println(“initialization failed. Things to check:”);

    Serial.println(“* is a card is inserted?”);

    Serial.println(“* Is your wiring correct?”);

    Serial.println(“* did you change the chipSelect pin to match your shield or module?”);

  } 

  

  // print the type of card

  Serial.print(“\nCard type: “);

  switch(card.type()) {

    case SD_CARD_TYPE_SD1:

      Serial.println(“SD1”);

      break;

    case SD_CARD_TYPE_SD2:

      Serial.println(“SD2”);

      break;

    case SD_CARD_TYPE_SDHC:

      Serial.println(“SDHC”);

      break;

    default:

      Serial.println(“Unknown”);

  }

void loop () {

  if (rf12_recvDone() && rf12_crc == 0) {

    Serial.println(F(“Receive data”));

    for (byte i = 0; i < rf12_len; ++i)

      Serial.print(rf12_data[i]);

    Serial.println();

  }

 

  if (sendTimer.poll(3000) && rf12_canSend()) {

    Serial.println(F(“Send data”));

    rf12_sendStart(0, payload, sizeof payload);

  }

}

 

YIPPEE!  I got the following output on my terminal windows when I ran these sketches:

Base System Serial Output

JeeNode Serial Output

Card type: SDHC

Receive data

72101108108111330

Send data

Receive data

72101108108111330

Send data

Receive data

Send data

Receive data

72101108108111330

Send data

Receive data

72101108108111330

Send data

Receive data

 

Note on the serial output for the Base Station there is info coming from both the SD Shield and the RFM12B.

SPI Misbehaving – Add the cc3000 to the SD Shield and RFM12B

I set the CS pin for the cc3000 to pin 8.  Now the SD Shield uses pin 10 for its CS, the RFM12B uses pin 9, and the cc3000 uses pin 8. 

So what happens when I put the components that share the SPI bus – the RFM12B board, SD Shield, and cc3000 – in the same sketch?  All is fine when the SD Card and the RFM12B board share the card.  Unfortunately, when I added in the cc3000, the Base System could no longer receive data.  

Drat… back to the Adafruit forum to see if I could get help troubleshooting.

Postby ktownsend » 05 Nov 2013 18:08

I really don’t know what this could be off the top of my head.
The TI modules do use a less common SPI mode (most devices use Mode 0). Alternatively, perhaps when the interrupt fires on the TI the CS lines on the TI side asserts at the same time that the CS line on the other module is asserted, so both devices are listening and everything goes off into the weeds?
The best solution would be to hook up a logic analyzer if you have one (Saleae Logic, etc.) and see if both CS lines at some point are asserted, just as somewhere to start?
Kevin

and

Postby adafruit » 06 Nov 2013 01:37

the breakout version of the cc3000 needs something to buffer MISO as it is not tristated
http://learn.adafruit.com/adafruit-cc30 … onnections
you can look at the cc3000+SD example sketches for how to share the SPI lines, but no, the CC3000 does not work great with other SPI devices without a lot of care & debugging. this kind of stuff is not easy to fix, if you’re “new to electronics”, you may find this project challenging and we don’t offer coding or library modification support and assistance.
our suggestion is to find an RF module that does not require sharing those pins. 

There was another thread in the forum that discussed other issues (and refers to the cc3000’s use of SPI mode 1):

by adafruit_support_rick » 23 Aug 2013 18:56

SD sets up the SPI control register once when you call begin(), and expects it to be correct forever after. Well-behaved SPI drivers should save SPCR, reconfigure it for their own purposes, and then restore SPCR on the way out.

Postby toegap » 27 Aug 2013 04:32

You are right about the SPCR. That needs be different for each of the libraries. If both libraries are set to SPI_CLOCK_DIV2, the only difference is that cc3000 uses SPI.setDataMode(SPI_MODE1) while sdfat(sd card) uses SPI.setDataMode(SPI_MODE0). Both of these effect the state of the SPCR variable. So you need to toggle the SPCR back and forth when you are using these libraries.

hmmmm….if anyone reading this has any suggestions – Please leave a comment.

Next Steps

 I want to complete the Base System.  I’ll look at the best options for: 1) wireless between nodes 2) Internet connectivity to send/receive from the Internet and 3) data logging.   I’ll also delve a bit more into the SPI challenge/conflicts noted above.  It looks like a good opportunity to learn!

Until next time…

 

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Google
  • Email
  • Pinterest

Like this:

Like Loading...

Prototype: Sending Sensor Data to a Web Site

17 Tuesday Sep 2013

Posted by bitknitting in 802.11, Arduino, Prototypes, Sending Sensor Data to a Web Server

≈ Leave a comment

Tags

Prototypes

My usual starting plead:  I am learning.  I’d love to hear from you about stuff I could do better @bitknitting or please leave a comment. 

This prototype is broken into two parts:

  • Arduino communicating with web server: An Arduino and 802.11 chip that speaks to each other such that the 802.11 chip can connect to a web server.
  • Sending data from the Arduino to a local web service running PHP.  This step takes the first one a bit further using a local web service and PHP to send data from the Arduino to a web site using PHP.

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Google
  • Email
  • Pinterest

Like this:

Like Loading...

Part 2: Send Data to a Home Web Server

16 Monday Sep 2013

Posted by bitknitting in 802.11, Arduino, cc3000, Cloud Services, PHP, Prototypes

≈ 21 Comments

Tags

802.11, arduino, cc3000, Cloud Services, Internet, IoT, PHP, wireless

In a previous post, we connected AdaFruit’s cc3000 wiFi breakout board connected to the AdaFruit server and read some html.  This time we will talk from our cc3000 to a web server running PHP.  To do this we will need:

  • Access to a web server.  For this I installed and started up MAMP on my Mac.
  • A web service that can take in and show data coming in from our cc3000.  We’ll use a simple PHP script.
  • An Arduino sketch that sends data over the WiFi to the web service.
  • Arduino wired to cc3000 with the ability to load and run sketches (see the previous post)

ArduinoToMAMP

What luck! Marco Schwartz wrote a blog post on the Open Home Automation web site that does pretty much what we want to do. Marco’s example takes temperature readings and sends them via WiFi to a Web Server that is running HTML embedded with simple PHP scripts.  As noted in Marco’s post, the WiFi Weather Project’s GitHub repository is located here.

I used Marco’s wifi_weather_station.ino as well as a few of the example sketches that are included in AdaFruit’s cc3000 libraries.

Getting the Server side Up and Running

Follow Marco’s instructions and code to get the PHP scripts up and running on your local web server.

Getting the Arduino Sketch Up and Running

I wrote a sketch that sends a PHP GET request to my local web server.  I borrowed heavily from Marco’s sketch as well as the examples that come from Adafruits c3000 library.  Thank you to both.  The sketches were valuable learning tools and did the majority of the “heavy lifting” needed to be done to send data to a PHP service from an Arduino that communicates with a cc3000.

First, download the sketch I am about to walk through and open in up in your Arduino IDE.

Once that is done, load the simplePHPGet.ino sketch into your Arduino IDE.

Make sure to modify the lines that are unique to your setup.  These include:

// WiFi network (change with your settings !)
#define WLAN_SSID "myNetwork"
#define WLAN_PASS "myPassword"
// PHP's server IP, port, and repository (change with your settings !)
uint32_t ip = cc3000.IP2U32(192,168,1,5);
String repository = "/wifiweather/";

For this step I am not going to hook up a sensor.  Rather, I’ll set random values for the temperature and humidity and then create a “GET” request.  This request is then sent to my MAMP Web Server.

The MAMP Web Server looks for files in the wifiweather folder that I created and put Marco’s files in.

The PHP script in sensor.php runs which updates the Web Page with the (randomly generated) values for temperature and humidity.

The Web Server sends back the results.

…and repeat.

Here is a screen shot of the web client showing the latest readings for temperature and humidity:

wifiweatherWebClientScreenShotAnd here is debug output sent to the serial monitor while running the sketch:

Initializing...OK.
Connecting to network...Started AP/SSID scan

Connecting to henry2...Waiting to connect...connected!
Requesting address from DHCP server.......waiting
....waiting
....waiting
OK
30.00
424.00
...Connecting to Server
Connect to 192.168.1.128:8888
Connected
...Sending request:GET /wifiweather/sensor.php?temp=30.00&hum=424.00 HTTP/1.0
Connection: close
...Reading response
-------------------------------------
HTTP/1.1 200 OK
Date: Fri, 20 Sep 2013 21:20:07 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8x DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
Content-Length: 0
Connection: close
Content-Type: text/html
Cleaning up...
...closing socket
390.00
17.00
...Connecting to Server
Connect to 192.168.1.128:8888
Connect to 192.168.1.128:8888
Connected
...Sending request:GET /wifiweather/sensor.php?temp=390.00&hum=17.00 HTTP/1.0
Connection: close
...Reading response
-------------------------------------
HTTP/1.1 200 OK
Date: Fri, 20 Sep 2013 21:20:17 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8x DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
Content-Length: 0
Connection: close
Content-Type: text/html
Cleaning up...
...closing socket

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Google
  • Email
  • Pinterest

Like this:

Like Loading...

Part 1: Send Data from Arduino to AdaFruit’s Web Server

16 Monday Sep 2013

Posted by bitknitting in 802.11, Arduino, cc3000, Sending Sensor Data to a Web Server

≈ Leave a comment

Tags

802.11, arduino, cc3000, Cloud Services, Internet, IoT, PHP, wireless

To test an Arduino sending data to a web server, we need:

  • An Arduino.  I used an Arduino Uno.
  • A Solderless BreadBoard
  • Some copper wires
  • An 802.11 chip that can send and receive data from an Arduino.  I purchased the CC3000 from AdaFruit.  AdaFruit has started to provide TI’s CC3000 WiFi chip.  They wrote a library to talk to the CC3000 from an Arduino Sketch.  Adafruit is an excellent company to buy prototype parts from.  The forums are awesome.  Their tutorials are extremely helpful.  I’ve been very happy with the product, support, and learning offered from Adafruit.
  • A web server
  • An Arduino sketch that communicates with the Web Server.

The CC3000 is Connected…to the Arduino

The first step is to get the CC3000 talking to the Arduino.

The CC3000 uses SPI to talk to the Arduino.  SPI supports multiple components talking to an Arduino.  The Arduino acts as a master SPI device.  The wiFi breakout acts as a slave. Different Arduinos use different pins to connect to SPI devices.  The Arduino Uno uses pins:

  • 13 to connect to a slave’s SCLK
  • 12 to connect to a slave’s MISO
  • 11 to connect to a slave’s MOSI
  • and usually a default of 10 to connect to a slave’s SS.

wifiToArduino

You may want to refer to the SPI entry in Wikipedia if the acronyms and what they represent are unfamiliar to you.

Each slave device needs a different pin to talk to the slave’s SS device.  This can be a challenge because it means the component and the library that speaks to the Arduino must support configuring a different pin to SS.  Components/libraries should do this easily so that multiple components can use SPI.  Luckily Adafruit’s breakout does do this easily. Yay!

There will also be another RF component to talk between Arduinos within the house. This component will also use SPI.  How this is handled will be discussed in a later post.

Once you have the cc3000 wired up to the Arduino, grab AdaFruit’s cc3000 library on GitHub library and run the buildtest sketch.  Don’t forget to set the WiFi’s SSID and password to the values used on the WiFi you wish to connect to!

I got the following results when a ran the buildtest Example sketch that comes with Adafruit’s library:

Hello, CC3000!
RX Buffer : 131 bytes
TX Buffer : 131 bytes
Free RAM: 1236
Initialising the CC3000 ...
Firmware V. : 1.19
MAC Address : 0x08 0x00 0x28 0x57 0x35 0x8E
Started AP/SSID scan

Networks found: 3
================================================
SSID Name : NETGEAR-lp
RSSI : 54
Security Mode: 3
SSID Name : henry2
RSSI : 78
Security Mode: 3
SSID Name : henry1
RSSI : 54
Security Mode: 3
================================================
Deleting old connection profiles
Attempting to connect to henry2
Started AP/SSID scan
Connecting to henry2...Waiting to connect...Connected!
Request DHCP
IP Addr: 192.168.1.218
Netmask: 255.255.255.0
Gateway: 192.168.1.1
DHCPsrv: 192.168.1.1
DNSserv: 192.168.1.5
www.adafruit.com -> 0.0.0.0
 Pinging 0.0.0.0...Pinging 0.0.0.0 5 times
Req report
Reports: 1
Sent: 0
Recv: 0
MinT: 0
MaxT: 0
AvgT: 0
0 replies

Closing the connection

Yippee! The CC3000 connected to the wireless network.  BUT bummer…name resolution of http://www.adafruit.com did not return its address and pinging http://www.adafruit.com didn’t work.  Typical isn’t it?  There is excitement on what works “easily” in our prototypes and confusion (leading to frustration) on a few things that should work.

After several runs, the call to cc3000.getHostByName(WEBSITE, &ip) resolved.  This is certainly not robust.  I assume I’ll run into this “bug” in the near future and thus will wait to debug further.

www.adafruit.com -> 207.58.139.247
 Pinging 207.58.139.247...Pinging 207.58.139.247 5 times
Req report
Reports: 2
Sent: 0
Recv: 0
MinT: 0
MaxT: 0
AvgT: 0
0 replies

However, pinging still doesn’t work.  I can’t figure out why so I am asking about it within Adafruit’s forum.

Conversing with AdaFruit’s Web Server

The Adafruit library includes another example sketch – WebClient.ino – that connects to http://www.adafruit.com and then sends an HTTP GET command:

GET /testwifi/index.html HTTP/1.0
Host: www.adafruit.com
Connection:close

And Yippee! The cc3000 connected with http://www.adafruit.com and then returned the contents of http://www.adafruit.com/testwifi/index.html.

The sketch returned:

Hello, CC3000!
Free RAM: 1125 bytes
Initializing...
Started AP/SSID scan
Connecting to henry2...Waiting to connect...Connected!
Request DHCP
IP Addr: 192.168.1.218
Netmask: 255.255.255.0
Gateway: 192.168.1.1
DHCPsrv: 192.168.1.1
DNSserv: 192.168.1.5
www.adafruit.com -> 207.58.139.247Adafruit_CC3000_Client::Creating socket ... 
Adafruit_CC3000_Client::Created socket:0)
Adafruit_CC3000_Client::Connect to 207.58.139.247:80
Adafruit_CC3000_Client::Connecting socket ... 
Adafruit_CC3000_Client::DONE
-------------------------------------
HTTP/1.1 200 OK
Date: Mon, 16 Sep 2013 15:45:22 GMT
Server: Apache
Access-Control-Allow-Origin: http://learn.adafruit.com
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Accept-Encoding, Authorization, Referer, User-Agent
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000
Last-Modified: Thu, 27 Jun 2013 14:13:27 GMT
Accept-Ranges: bytes
Content-Length: 74
Connection: close
Content-Type: text/html
This is a test of the CC3000 module!
If you can read this, its working :)
Adafruit_CC3000_Client::No more data, and closed!
-------------------------------------

On to sending data from the cc3000 to a web server running on the same intranet.

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Google
  • Email
  • Pinterest

Like this:

Like Loading...
Advertisements

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Archives

  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013

Categories

  • 3D Pringint
  • 433MHZ
  • 802.11
  • A Salad A Day
  • ADC
  • Analog Circuits
  • Arduino
  • Atlas Scientific
  • Audio Recording
  • Base Station
  • BTLE
  • cc3000
  • Cloud Services
  • Conductivity
  • Contextual Electronics
  • Data Logging
  • debugging
  • DHT22
  • Diagnostic Tests
  • doxygen
  • DS18B20
  • EC
  • Eclipse
  • electronics
  • Healthy EC Shield
  • Healthy pH Shield
  • Herbs
  • Home Network
  • Hydroponics
  • indoor gardening
  • JeeLabs
  • Ladybug Blue
  • Ladybug Nutes
  • Ladybug Plant Food Adjuster
  • Ladybug Shield
  • LED
  • Lettuce
  • LTSpice
  • Moteino
  • New Category
  • New Project
  • nRF24L201
  • nRF51822
  • Nutrients
  • Othermill
  • PAR
  • PCB
  • pH
  • PHP
  • power supply
  • Prototypes
    • Building Our First LED Circuit
    • Sending Sensor Data to a Web Server
    • Wireless Communication Between Sensors
  • Readings
  • RFM12B
  • RFM69
  • Schematics and Board Layout
  • sensors
  • sling
  • soldering
  • SparkysWidgets
  • TCS34725
  • temperature
  • thermistor
  • Uncategorized
  • Vegetables
  • virtual ground
  • Voice Recording

Meta

  • Register
  • Log in

Blog at WordPress.com.

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.
Cancel
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy
%d bloggers like this: