SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By follower
#115284
follower wrote:
luwii wrote:If you modify the subsections of of switchToCommandMode, more specifically WiFlyDevice::attemptSwitchToCommandMode() in WiFly.cpp then I don't seem to be able to connect to the WiFi network (Not too worried why)
Do you mean if you make the change in 'attemptSwitchToCommandMode' rather than client close it doesn't work? Odd.
Yeah, I can confirm this is the case for me as well. Which doesn't make it less odd. :) It seems to be failing at very first attempt to enter command mode.

After looking into it more I think I'm going to try a different approach to library startup. The combination of board versions, firmware versions, possible configurations, module state and timing means it's non-trivial to handle every possible startup state--especially for the older boards that don't have hardware reset functionality.

--Philip;
#115309
Before I had a yellow and green flashing LED.

Using "0" as the passphrase for a unsecure network worked and I just had a green flashing LED.

It looks like there was a problem with the DNS somewhere and I put in the IP address for a website causing my green LED to stay solid and I was able to communicate.

Thanks for you work follower.
#115386
follower wrote:
luwii wrote:I noticed the documentation for the V2.21 firmware of the WiFly indicates that the 1 second boundary before and after the $$$ has now been reduced to 250ms.
Which version of the datasheet did you see that said 1 second? I've only ever send the 250ms specified.
(Download the manual directly from the Roving Networks site, the link in Sparkfun is for older firmware version.)
To which link on the SparkFun site are you referring?

--Philip;
The link I'm talking about is in the SpeakerJet tutorial, http://www.sparkfun.com/tutorials/158, called "WiFly User Guide"
and the document opened is a 2009 version of the WiFly module
See page 13 under the $$$ section.
#115413
luwii wrote:The link I'm talking about is in the SpeakerJet tutorial, http://www.sparkfun.com/tutorials/158, called "WiFly User Guide"
Thanks for pointing that out, I was looking at the link on the product page. :) I've added a link in the tutorial to a more recent version.
and the document opened is a 2009 version of the WiFly module
See page 13 under the $$$ section.
Ah, yes, I see that now. Weird, the way they mention it in the release notes makes it sound like before it was 250ms the guard time didn't exist at all. Good to know.

Thanks again for showing me that.

--Philip;
#115517
It's been a little more than two weeks since I last SFE tech support for help. Nothing yet.

On the flip side, I have gotten an Arduino Ethernet Shield up and running. I'm not having any problems with that system over my network.

Anyone have any additional ideas as to why I can't get into command mode with the WiFly shield?
#115605
StaticDet5 wrote:It's been a little more than two weeks since I last SFE tech support for help. Nothing yet.
I couldn't quite parse that, you mean you haven't heard from SFE tech support since you contacted them two weeks ago?
Anyone have any additional ideas as to why I can't get into command mode with the WiFly shield?
Okay, let me follow this:

The current problem is you get "junk" characters instead of useful output. On re-reading this response I realise it would have been more useful if I'd gone into more detail, so consider this an update. :)

I was reminded recently that the most recent version of the board connects the factory reset pin of the WiFly module to one of the GPIO pins of the SPI UART. This means it's possible to control the SPI UART and get it to trigger the factory reset of the WiFly module.

And, the good news is, I've written a tool to do this for you. :)

Do you know how to use GitHub? The tool is currently available as HardwareFactoryReset.pde but it requires the current version of the SPI UART code which hasn't yet been released. If you can use GitHub you should be able to pull everything from there. Otherwise, let me know, and I'll do a proper alpha release. [Update: Done, see below for alpha 2 release.]

If a hardware factory reset doesn't work then I would say it's probably a hardware fault again.

--Philip;
Last edited by follower on Thu Dec 16, 2010 6:23 am, edited 1 time in total.
#116160
StaticDet5 wrote:It's been a little more than two weeks since I last SFE tech support for help. Nothing yet.

On the flip side, I have gotten an Arduino Ethernet Shield up and running. I'm not having any problems with that system over my network.

Anyone have any additional ideas as to why I can't get into command mode with the WiFly shield?
Having the exact same problem. I tried different baud rates, still get garbage after the chip says 'Bridge successful'. The chip doesn't create a wireless network on startup with pin 9 set to 3.3V on startup either.

EDIT: This is with the RN-131G chip, got it not so long ago, and they're already on a new version!

Also, setting the wifly to connect to two different wifi networks (with a bunch of different settings) did not work.... but at least prints out the full text output:

Set wlan to level....
blah blah blah
Failed to authorize....
#116193
Hi,
nflacco wrote:Having the exact same problem. I tried different baud rates, still get garbage after the chip says 'Bridge successful'.
Can you please try installing the Alpha 2 library, then use the "HardwareFactoryReset" tool included. Once you've done that can you then try the 'SpiUartTerminal' tool included and post your results?
EDIT: This is with the RN-131G chip, got it not so long ago, and they're already on a new version!
I think the difference between the G and C versions is just the temperature range they operate within.
Also, setting the wifly to connect to two different wifi networks (with a bunch of different settings) did not work.... but at least prints out the full text output:

Set wlan to level....
blah blah blah
Failed to authorize....
From looking at the code that example doesn't check for a response until the end so it's probably not actually communicating successfully--it probably just reads the "garbage" you see.

Also, have you contacted tech support about this?
--Philip;
#117663
follower wrote:Also, have you contacted tech support about this?
New Arduino/new wifly, same issue. After more time with tech support...

The ics are fine. Turns out it was a crystal issue. We apparently have a 14 MHz crystal, which needs the spi_uart stuff set at 60, vs the 12 MHz which requires 50 (we had it at the latter, but needed the former).
#118197
Hi all,
I bought my Wifly shield in Oct, 2010 and finally got a chance to spend some serious time with it. Have similar problem that StaticDat5 did -- both Yellow and Green blink fast and asynchronously. this is the pattern, http://www.youtube.com/watch?v=sVdQUKgmfho

I have been following the thread and tried the SpiUartTerminal sketch, and all the Wifly example sketches and no luck.
In WiFly_Auto_ Connect, WiFly_WebClient: I can't get pass anything beyond this function call -- WiFly.begin();
In HardwareFactoryReset, SpiUartTerminal: can't pass SpiSerial.begin();
it reads "Attempting to connect to SPI UART..." and no more response from the shield.

My crystal is 14.2456 Mz and I have changed the value like so: from 0x50 to 0x60 in the
struct SPI_UART_cfg SPI_Uart_config = {
0x60,0x00,0x03,0x10};

I wonder if my WiFly is defective or not.
#118220
Here's the thing:
I don't know why mine started working.
I updated the Arduino environment, and went to Follower's version 2 of the WiFly library.

Because of my notes, I was able to duplicate EVERYTHING (right down to what the Arduino was sitting on) in my tests from before. One day it was working, the next day it wasn't.
#121820
@ knychw : Did they send you a new WiFly shield? Did the new one work?

I too have the same problem. Brand new WiFly (rev3), Arduino Uno SMD, alpha 2 lib, and using Arduino 022.
Same blinking lights pattern, and can't get anything past 'Attempting to connect to SPI UART...'

Any other way to test this thing?
  • 1
  • 3
  • 4
  • 5
  • 6
  • 7