I would like to make sure that the workaround for borked responses from the
CC3000 is clearly delimited in comments or #ifdefs, so that when we get the
results to be reliable, we can remove that extra complexity.


On Mon, Mar 17, 2014 at 9:17 AM, Technobly <notifications@github.com> wrote:

> In src/spark_wiring_network.cpp:
>
> > @@ -55,4 +55,38 @@ char* NetworkClass::SSID()
> >  	return (char *)ip_config.uaSSID;
> >  }
> >
> > +/*	***********************************************	*/
> > +/*	* Network.RSSI() - @TimothyBrown - 2014.03.17 *	*/
> > +/*	***********************************************	*/
> > +/*	----------------------------------------------------------------------------------------------------------------------------------------------	*/
> > +/*		This function returns the WiFi signal strength in -dB [-127 to 0]. Error Values: 1 [CC3000 Problem]; 2 [Function Timeout/Bad Data].			*/
> > +/*		It reads through all entires in the table, continuing even after finding the correct SSID; this prevents stale entries on the next call.	*/
> > +/*		There is a one second timeout on the function for safety; this also forces the function to re-run if the results table is corrupt.			*/
> > +/*		Note: The CC3000 only updates the RSSI status every few minutes, so this function doesn't need to be called constantly in the main loop.	*/
> > +/*	----------------------------------------------------------------------------------------------------------------------------------------------	*/
> > +int8_t NetworkClass::RSSI()
> > +{
> > +	_functionTimeout = millis() + 1000;
> > +	_loopCount = 0;
> > +	_returnValue = 0;
> > +	while (millis() < _functionTimeout)
>
> if _functionTimeout = millis() + 1000; is called right before it millis()
> wraps, while (millis() < _functionTimeout) exit early or immediately.
> It's once in a blue moon, but subtraction method is better way to CYA. while
> ((millis() - startTime) < 1000)
>
> That said, I'm not sure it's going to work how you intended it to. If you
> break out of the inner while() loop because your wlan_scan_results_table[0]
> == 0 (results are corrupted), and you intend to re-run the function,
> wouldn't you want to also reset _loopCount = 0; maybe right above the
> inner while() loop? I don't understand why a 0 gets inserted into the
> results table, but if so and you don't reset _loopCount it's just going to
> continue on until it gets to 16.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/spark/core-firmware/pull/152/files#r10657339>
> .
>



-- 
Andy