Can I Turn the CC3000 OFF? [solved]

Troubleshooting
21

@Dave @BDub @bko @satishgn @david_s5 @Dave @mattande @zachary @zach @timb

Hey guys what do you all think is the easiest way for a beginner like me to "Run Setup/loop regardless of WiFi Status?"

Right now if there is no Wifi the Spark becomes useless which is keeping me from moving forward.

All help is appreciated.

22

Hi @RWB nd @Dave

The problem is not really running without WLAN or the cloud, the problem is how you say that in the webIDE due to the timing of which code runs at what time in the start up sequence, and how your code would recover and turn the WLAN and the cloud back on when you need them. Satish's commit above:

says that by putting this line above the setup() function, you can turn off cloud connections. This is a special way a user has to write this so that it runs before the cloud connections start.

Another approach would be some kind of check box in the webIDE that controls the #define's to turn on and off the cloud and the WLAN.

Yet another approach might be to have a "lazy" WLAN and cloud where the network and the cloud don't startup until you try to use them. We would then have the problem of having the user turn them back off safely when done.

With either way of turning things off, if you then want to turn those services back on, right now you have to know a bit about how the :spark: works but in the future this could be wrapped up in easier to use code.

I think @zachary and @satishgn have your feature request for more control over and the ability to work with the cloud or the entire WLAN offline. I think the way they will provide this feature is still being thought out and developed, but the above commit to allow you to turn off the cloud is the first step.

3 Likes
23

bko, I agree totally. There is a lot of thought by a bunch of very smart folks going into crafting how the user program and the core firmware interact without interruption. RWB, as bko pointed out, the solution which will evolve sooner than later, will undoubtedly end up being simple for the user. The Spark is NOT an arduino but the Team is shooting for arduino simplicity.

2 Likes
24

Just dropping in to say I tested satishgnā€™s commit that allows us to use SparkClass SparkConnect(false); above void setup() and it works perfectly. I also ran Spark.connect() some time later in my code and that worked fine as well. This is not a bad solution, but itā€™s arguable hard for most users to understand why it works.

I like check boxes, but it would be nice if itā€™s baked into the way we code our apps and is universally the same when building locally or online.

Iā€™m trying to think of ways that are intuitive for a user, like setup() and loop() are.

Would it be more or less intuitive to add a function that can be optionally defined in our user code called init() where we could set up various things like SPARK_SOCKET_HANDSHAKE = 0; that would be run before the main loop in the main.cpp file?

2 Likes
25

@BKO Thank so much for an answer that is easy for me to understand!

When there is code that I can run by compiling locally then let me know, I here to help test and provide feedback to help progression.

26

@RWB there is code right now :smile:

Grab the latest MASTER of all 3 reposā€¦ add your code to application.cpp and donā€™t forget to add #include "application.h" to the top ā€¦ add the SparkClass SparkConnect(false); above your setup() routine and compile. You will be happy :wink:

27

@BDub If you have something cooked up that will work for me now let a brother know :smile:

28

Hey brotha from anotha motha, check above! :smile:

29

@BDub Awesome! LOL :smile:

So after I load all that up I will use SparkClass SparkConnect(false);to keep my loop running regardless of the CC3000 status?

What exactly is this SparkClass SparkConnect(false); doing? Is it totally disabling the CC3000? Just keeping the Spark from freezing up? Will the CC3000 still try to connect to the internet? or will that no happen until we call for Spark.connect()

It sounds great, I'm just trying to understand exactly what I should expect to happen.

30

BDub, if I understand correctly, calling Spark.connect() will not re-run the user setup() but only restart loop(), correct? And if you call Spark.disconnect(), loop() keeps running. So can I assume that a Spark.connect in the middle of your loop wonā€™t take affect until loop() ends and it relinquishes control to the firmware?

Another way of doing without the SparkClass thing is to set the flags in a file similar to application.h. The user is already required to include it (except for .ino!). So why not add #include nocloudstart.h before application.h if they want to start with no cloud connection?

31

Hey @BDub and everybody,

Totally agree that SparkConnect(false) is not a bad solution, but the exact way you have to do this is definitely an advanced maneuver for most Arduino users.

I donā€™t really like the check box thing either but some of them may be inevitable.

We have another way from @peekay123 with #includes, which could work fine too.

For simplicity, how about something like:

void setup() {
  Spark.WLAN(true);
  Spark.cloud(false);
  ...
}
3 Likes
32

bko, it needs to be outside the setup() code for it to work, at least for the startup state. I like the idea though of controlling the WLAN and cloud separately.

33

Hi @peekay123

My point is that it needs to outside setup() the way it is presently architected but that is not the only way it could done. I get it for today: using a global constructor was my idea back up there in this thread somewhere!

Sometimes simplicity comes at the cost of a bit of a rewrite :smile:

2 Likes
34

bko, Iā€™m with you bro :smiley:

35

Correct, setup only ever runs once.

Yes Spark.disconnect()/connect() just schedules the WLAN to be disconnected/connected and happens when your loop() ends and the code goes into the SPARK_WLAN_Loop(); routine. And when it's connecting it does block you loop() for a bit while it does it's stuff... not sure how long disconnect() blocks for... but connect was at least a second or so.

1 Like
36

Thanks BDub! So you need careful planning when using these if you have time critical code. Food for thought :smile:

1 Like
37

@BDub So when we call Spark.Connect will the delay extend if it is not able to connect to the WiFi network quickly or at all?

38

Thatā€™s a great question @RWB. Let me check! So if I try to run Spark.connect() after the first 10 seconds of operation while the Spark has been disconnected from the time we powered up, and my wifi is OFF ā€¦ my user code is blocked indefinitely. I waited several minutes and itā€™s just sitting there trying to connect forever. Fail. @david_s5 @satishgn

BTW earlier I saw the flashing blue LED issueā€¦ my phone completely died while my wifi hotspot was on while the Core was connected and running user code. When I charged the phone back up and it powered up with the wifi hotspot on again, the Core just keeps flashing blue, dead in the water.

1 Like
39

Hi All,

Thanks for providing with the valuable feedback.
I like the idea of ā€œincludesā€. So I will work on this plan.
1)Provide 2 inlcudes: ā€œspark_wlan_disable.hā€ and ā€œspark_cloud_disable.hā€ with an utility class, object instance etc. so you can disable wlan and/or cloud from the webIDE.
2)Move just the Spark_WLan_Setup from startup into main() after constructor and provide additional conditional checks.
Any objections let me know!
@BDub, I will look at the issue and provide necessary checks.

Thanks

1 Like
40

Hey All,

We got most of the above things implemented and related bugs fixed.
The 2 includes that users can use :
spark_disable_wlan.h and spark_disable_cloud.h

I just thought of adding a Spark.wlan(boolean) function which application.cpp can use to enable/disable WLAN at will.

Also we need to have new RGB Led color management:
WLAN disabled: Breathing WHITE (This works now when you include the wlan disable include)
WLAN connecting: Flashing GREEN (works now)
WLAN connected and Cloud disabled: Breathing GREEN (pending). Currently this will flash GREEN with cloud disable include.

By Friday, we will wrap this up.

Thanks

4 Likes