Page 5 of 7

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Wed Dec 08, 2010 10:05 am
by codester
I am having the same problems as other people.

Typing $$$ has no effect when using the terminal program.

When I try a example sketch the green LED flashes fast and the yellow LED flashes slower (but i think it is still considered fast.) From the user guide the green means no IP and the yellow means Rx/Tx data transfer. Since the red is not coming on I guess that means the SSID and passkey are ok? The examples seem to hang up on this line:
Code: Select all
  if (!WiFly.join(ssid, passphrase)) {
Anyone have any ideas as to what I am doing wrong?

Thanks

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Wed Dec 08, 2010 3:58 pm
by croyles
I am getting a bit concerned.
To enter / exit command mode takes over a second?

If its running as a server or client, and you have to enter command mode to disconnect after every response and it takes over a second, thats not going to scale / function well at all. Having doubts about if this is right for my application.

Is there a faster more stable way of starting / ending the connection?

I tried keeping the connection open, but all attempts to buffer the output (so I could get the length of the response and add it to the header) resulted in me blowing the memory out or getting currupt strings from String.concat() methods.

I cannot even get a basic web form running because the connection is not closing consistently.

Either there is a design flaw in the way this works, or we are missing something?

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Wed Dec 08, 2010 4:03 pm
by croyles
codester wrote:I am having the same problems as other people.

Typing $$$ has no effect when using the terminal program.

When I try a example sketch the green LED flashes fast and the yellow LED flashes slower (but i think it is still considered fast.) From the user guide the green means no IP and the yellow means Rx/Tx data transfer. Since the red is not coming on I guess that means the SSID and passkey are ok? The examples seem to hang up on this line:
Code: Select all
  if (!WiFly.join(ssid, passphrase)) {
Anyone have any ideas as to what I am doing wrong?

Thanks
WEP 64 bit is not supported, and WPA requires you to edit the join method, changing to 'key', rather than 'passphrase' in the connect method.

This is another thing I struggle with ... we have to determine the encryption type (call the right 'get' command) before connecting, in order to then establish the right type of connection with the network.

Good luck, when it connects it connects well, and seems pretty stable.

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Wed Dec 08, 2010 5:42 pm
by codester
The WiFi I am trying to connect to has no protection so I use "" as the passphrase
croyles wrote: WEP 64 bit is not supported, and WPA requires you to edit the join method, changing to 'key', rather than 'passphrase' in the connect method.

<snip>

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 4:49 am
by luwii
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.

(Download the manual directly from the Roving Networks site, the link in Sparkfun is for older firmware version.)

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 6:05 am
by follower
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;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 6:10 am
by follower
I'll also post this as a separate thread but--for those of you who have been waiting--the main WiFly source repository is now available on GitHub here: https://github.com/sparkfun/WiFly-Shield

I've just gone ahead and imported the source from the alpha 1 release with no modifications.

I'll work on applying the changes I've made since then directly.

--Philip;

P.S. For those who are interested I'm using the hg-git Mercurial plugin so I don't actually have to use git in order to use GitHub. :)

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 11:06 am
by follower
Okay, this is a group reply--if you're having trouble getting the WiFly shield to work please read this.

I've made a post Troubleshooting the WiFly shield for Arduino which includes a link to a tool that should make troubleshooting easier.

Please follow the instructions in the post and then re-post in this thread with how far through the steps you got successfully. Hopefully this will help narrow down the possible issues.

Thanks.

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 11:27 am
by follower
Hi,

Please read the "group post" I made above.
croyles wrote:On a completely seperate topic, I found another WiFLy terminal test harness, but it uses stdio.h, which is not in my library list, or appears to be installed. Do I need to download this?
No.
follower wrote: The code to detect connection failure hasn't been written--the code is just hanging because it's not getting the expected response. If it gets as far as the join method call then I would think it is actually communicating with the module okay.
Good point, if it does not receive the "Associated!" command its going to run until it get to EOM. Would that not return a false to :join() and fall through?
If the code had been written, yes. But it hasn't been written so it just gets into an infinite loop and never fails. The troubleshooting tool I mentioned in the post above avoids any configuration of the WiFly module itself entirely.
I will try this, its interesting you note this, as the module should be in 'command mode'. Does the module remain in command mode across reboots?
If only the Arduino is reset (via reset button or auto-reset from IDE) then the WiFly module stays in its current state. If the WiFly module is *actually* rebooted/reset (which doesn't normally happen) then it should exit command mode. If the power is removed from the Arduino and the module and then replugged (one of the required troubleshooting steps) then the WiFly module should no longer be in command mode when power is applied. (I say "should" because I've had a situation where a (I think) beta firmware caused command mode to sometimes be entered into automatically after an upgrade and/or power was applied--can't remember the specifics but hopefully it shouldn't happen to you. :)
follower wrote: Also, to make things easier to track I suggest unpowering the Arduino and WiFly shield after uploading a sketch until you sort things out.
Sorry not sure what you mean by 'unpowered', it needs to be powered in order to send serial commands?
That should have been "unpowered and then repowered" (i.e. unplugged and then plugged in).
I have been using simple Serial.print messages to debug, are there other approaches?
Not really.

Hopefully this post and the troubleshooting tool will help isolating the issue you're having with the board.

Thanks for your patience with this.

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 11:31 am
by follower
croyles wrote:UpdateI have successfully associated with a WiFi network (WPA) without modification to the library, it just worked. I have all examples pairing successfully.
Great.
I am looking for an example that puts the WiFly into Command mode, and then allows commands to be sent over Serial across to the WiFly, an the results to be printed into the Serial console. Preferably tested and working with the default Arduino SDK.
Please try the troubleshooting sketch referenced in the post above as it should allow you to do this.

--Philip;

Re: Comments on Alpha 1 release

Posted: Thu Dec 09, 2010 11:37 am
by follower
luwii wrote:I did however find various $$$ exit command repeated at the end of many web pages (I'm using it as a web server)
You may need a longer delay before you close the connection. If you compare the standard Ethernet WebServer example with the WiFly_WebServer example you'll notice the WiFly one includes a longer delay before closing.
It came from the Roving Networks spec sheet where it indicates a 1 second delay before and after a $$$ is required to switch to command mode. For me 400ms worked fine.
250ms on either side should work.
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.

The absence of the guard time for entering command mode is a "known issue" and is in the TODO list. :) Looks like enough people are encountering it I'll bump up the priority.

Thanks for your feedback.

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 11:40 am
by follower
codester wrote:Typing $$$ has no effect when using the terminal program.
Please try the troubleshooting tool I link to in the group post above.

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 11:43 am
by follower
codester wrote:The WiFi I am trying to connect to has no protection so I use "" as the passphrase
Ah, that might be the problem. Try specifying "0" as the passphrase or comment out the line in the library that sets the passphrase. (The WiFly module should parse the single "0" (zero) as indicating no passphrase. (Yeah, sucks if your passphrase is "0". :)))

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 11:50 am
by follower
croyles wrote:WPA requires you to edit the join method, changing to 'key', rather than 'passphrase' in the connect method.
Actually, it's WEP that requires you to edit the library at the moment.
This is another thing I struggle with ... we have to determine the encryption type (call the right 'get' command) before connecting, in order to then establish the right type of connection with the network.
This is a temporary limitation of the library--well, partly, as the module should really choose the correct option automatically because it can tell which choice to make. My plan is to support auto-selection by just setting both the passphrase and the key to the same value and ignoring any error that is returned. Hopefully then the module will then just do the correct thing. But because I don't know how it handles an invalid key/passphrase I haven't implemented the code that does this yet. But, hey, the repository is on GitHub now. :)

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Dec 09, 2010 11:55 am
by follower
Hi...
croyles wrote:To enter / exit command mode takes over a second?
No. Entering command mode should take 250ms + time to send $$$ + 250ms. (Except that I haven't implemented the guard time, yet, so YMMV more.) Exiting it shouldn't take any time greater than sending the characters.
If its running as a server or client, and you have to enter command mode to disconnect after every response and it takes over a second, thats not going to scale / function well at all. Having doubts about if this is right for my application.
What's the application you're envisaging using this for? If one second is going to make a difference and you're concerned about scaling the current limitations of the library/module might be issues. But I'd need to know more about your scenario.
I tried keeping the connection open, but all attempts to buffer the output (so I could get the length of the response and add it to the header) resulted in me blowing the memory out or getting currupt strings from String.concat() methods.
I strongly recommend using the TextFinder library rather than using String.

Thanks for your feedback and patience--people are only really starting to push the boundaries of this. :)

--Philip;