JavaLaurence Geschrieben January 28, 2013 at 17:24 Geschrieben January 28, 2013 at 17:24 Hi, I managed to get the Wifi extension talking to my wireless router. The router shows the extension's MAC address as associated. The router's DHCP assigned it an IP address which I use to connect to it via brickv. The connection is successful, so I go to the WIFI Extension info panel and press Show Status. The status window comes up, but the value fields remain empty. In the mean time, the Timeouts counter keeps counting up, incrementing at a steady rate of (roughly) 0.5Hz. I don't understand this behaviour. If the Wifi extension and the router are happy (connected), then why can't any data flow over the connection? BTW, when connecting to the stack over USB, I can see that the signal strength is -84 to -88dB. Is this very weak? It must be the same strength that my iMac is getting, sitting 30 cm further away from my router's antennas, and my Mac has decent bandwidth. Help. Zitieren
borg Geschrieben January 28, 2013 at 18:50 Geschrieben January 28, 2013 at 18:50 But the WIFI Extension works otherwise? To read the status of the WIFI module, the Master Brick has to change the module from data mode to command mode and back. This unfortunately takes quite a long time. If the connection to the module is not good either, it may happen that the getStatus call times out. I will change the update rate to something smaller for the next Brick Viewer version, that should fix this. Zitieren
JavaLaurence Geschrieben January 29, 2013 at 20:21 Autor Geschrieben January 29, 2013 at 20:21 Does the extension work? No it doesn't. So far I haven't tried anything at the API level, since I figured that I should first be able to check things out via brickv. So if Brickv cannot show the extension's status, I don't want to try anything else. Currently I'm completely stuck on two different fronts: power supply and wifi connectivity. Both are key to the water pump solution I'm trying to put together. I think that, in your own interests, you should include much more self-diagnosing AND logging capabilities in the general TF architecture. So that customer service is more efficient, with a lot less "Did you try X" and "Can you try Y".. and more "Easy, you made a simple mistake: do Z and all will be well, and by the way, we'll improve our documentation so that future customers won't fall into the same trap." I've now invested quite a bit of time writing software for my stack, so I'm determined to get this working 100%. But I will need your assistance. Maybe a new Step-Down will need to be mailed to me, unless you have other ideas to address that particular issue. Zitieren
borg Geschrieben January 30, 2013 at 14:00 Geschrieben January 30, 2013 at 14:00 But you can connect to the IP of the WIFI Extension and do the Bricks/Bricklets that are connected to the Master Brick show up, right? If that is the case, i highly suspect that it is a problem with the timing of the status refresh. Since the refresh makes the WIFI module unresponsive for a small amount of time. I took a look at the WIFI module datasheet. We could try to get the RSSI from another command that does not have so much overhead and do the rx/tx count ourself. All of the other information must only be obtained on connects/disconnects and not every time the getStatus is called. We will try to make a firmware that works this way, that you can test. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.