Spark core - disable cloud

Firmware
1

Hi all,

I’ve read many posts about using the core without the cloud but none of them seem to cover exactly what I want to do.

I want to operate my core completely without the cloud. (I’m doing 100% local development and debug.)

I am am using the core to implement a device that can take readings and allow other devices to retrieve the readings using CoAP. I’ve got basic stuff working but from time to time the core swallows the CoAP packet that I want to process with my code.

Also, the device will need to operate when there is no internet connection available as well.

I don’t want to use a local cloud because it would require another device to run the cloud. I want to be able to directly get readings from the core using an Android, iOS or Win mobile application.

I have tried MANUAL mode for the connection and called Spark.connect(); but my packets are never sent. I’m guessing that communications with the CC3300 is all driven somewhere in the Spark.process(); method. If I call that I’m right back to having the core’s code snatch my packets based on timing.

I’m thinking of combing through the code and disabling where the core processes packets, but that is no simple task, so I’m looking for a little direction or advice on a better way to do this.

TIA!

2

Manual mode requires you to turn on the WiFi module yourself. You shouldn’t need to ever call Spark.connect() if you don’t want to use the cloud.

How are you sending the COAP packets?

3

Thanks for the response!

I called Spark.connect(); and then a WiFi.connect(); and that “seemed” to turn things on (the core was breathing cyan) but if those calls are not enough to turn on the Wi-Fi then that would explain the behavior I am seeing! :smile:

I am sending the CoAP packets out over a UDP socket that I created.

As a follow up I ran a test in “AUTOMATIC” mode where I was sending my CoAP packet about once every 5 sec and it seemed that the only loss was the 1st packet sent back to the core after start up. But this still does not get me past the need to operate when there is no internet connection.

4

Oh, sorry. I misunderstood what you were doing.

How about something like this:

WiFi.on();
WiFi.connect();
while(WiFi.ready() == false);
delay(1000);
startSendingCOAPStuff();

In your setup. I really don’t know why that delay is required but I’ve found I always need it. Sometimes the first few WiFi attempts afterwords will fail anyway which is why I have implemented a limited retry scheme.

Have you attempted something similar? If so, try it out and get back to me/us

5

With code similar to what you show above the core starts up and after some other flashing goes to breathing green and I never see any packets sent. (I’m verifying with Wireshark)

6

Interesting… Have you, by chance, upgraded the firmware on your CC3000? If so perhaps you could share (even if it’s stripped down) a version of your code on a gist or github repo so we can “play along at home”?

7

I am “pretty” sure i updated the firmware, but can’t be 100% certain. I’ve been working on this off and on (more off than on) for quite a long time and I’ve lost track of if I updated the CC3000 or not.

I’m an extreme n00b with git but I will give it a shot at getting everything checked into a repo.

8

No worries. Do you have the CLI installed? How are you pushing code to your Spark Device?

If you’ve got the CLI installed go through this tutorial real quick: http://support.spark.io/hc/en-us/articles/203108844-Perform-a-Full-Firmware-Upgrade and then push your code back on there after tinker (so you can flash from the cloud if you wish)

9

Unfortunately I don't have the CLI installed and I don't think that O can get it to work because I'm currently developing on a Win7 VM in VirtualBox on Ubuntu. VirtualBox doesn't seem to like to attach the core to the VM. :grimacing:

I guess I'll give the CLI install a shot.

I'm programming the core with an STLink from NetBeans.

I'm assuming that will do the CC3000 upgrade and afterward I can just go back to flashing my firmware using the STLink with no problems.....

10

The CLI installs on Ubuntu I believe.

The full firmware upgrade does 3 things:

  1. Replaces your factory reset image of Tinker with the most up-to-date version
  2. Updates your CC3000
  3. Puts the latest tinker back on your device

You could theoretically skip step 3 if you had code ready to go on there. The CC3000 update updates the CC3000 and then puts it back into DFU mode and thus ready for new firmware

11

@harrisonhjones, I’ve recently dealt with a similar problem on another thread - although not exactly the same problem, but in my case it seemed to work by just adding this

  ...
  while(WiFi.ready() == false)
     SPARK_WLAN_Loop();
  ...
12

Interesting. I shall see if that speeds anything up

13

Unfortunately no luck when adding that method call.

14

Hi @Sailing_Nut

If you are using UDP broadcast (either global or subnet) to send your packets, there is a weird thing in the recent TI CC3000 patches that make UDP broadcast not work until you do some other network "thing". The minimal "thing" that I found was to ping the gateway (router) so that whatever is stuck in the TI part (likely ARP related) gets unstuck. Obviously with the cloud on, that unsticks the TI part for you.

See this thread for details:

1 Like
15

@bko You totally nailed it! I put in a ping to the default gateway and it cleared out whatever was hung up in the CC3000. I did have to do it after the 1 sec delay. If I put it before then it did not work.

But at any rate, I’m good to go and am able to move forward with my development.

I’m running a long term test with a CoAP “conversation” taking place about once every 2 sec and only one “missed” conversation and that was the very first one. (I attribute this to my bad code somewhere, either in the core or the .NET app I wrote to be my test harness.) I’m now up to just over 420 conversations and going strong!

4 Likes