New feature: control your connection!

michael1 · August 22, 2014, 7:52pm

from my understanding the connection to the button is just an example of what you can do in semiautomatic mode. You can use any other pin by adapting the code ( attachInterrupt(D0, connect, FALLING) or do not use a button at all and call Spark.Connect() in some other place in your code.

mdma · August 23, 2014, 8:55am

@michael1 - let’s take this discussion back over on the original discussion thread for the subscribe problem.

markopraakli · August 25, 2014, 7:15pm

Has anyone had a problem with SYSTEM_MODE(MANUAL) and OTA updates? If I set MANUAL and I try to do OTA uptade then core led is solid magenta and then resets it. In loop function I have this:

if(Spark.connected()){
        Spark.process();
        if(serverStatus == 1){
            serverStatus = 2;
            Serial.println("HELLO");
        }
        if(serverStatus == 0){
            serverStatus = 1;
        }
    }else{
        Spark.connect();
        serverStatus = 0;
    }

Do I missing something or it is a bug?

markopraakli · August 27, 2014, 6:38am

Does anyone tried it or perhaps Spark employees can investigate it @zach ?

mdma · August 27, 2014, 9:32am

I can take a look at this the next day or two - from what I know of how this works, this could likely be a bug, since MANUAL mode is expecting user code to call Spark.process() but that is of course not possible during a OTA update.

Until a fix is available, can you use SEMI_AUTOMATIC mode?

kennethlimcp · August 27, 2014, 11:48am

I’m trying to help debug this but my core will not even enter breathing cyan in Semi_auto or manual mode…

Weird!!

mdma · August 27, 2014, 11:53am

That’s by design. With those two modes, the core starts of disconnected. (The change to semi-auto was quite recent.)

The semi-automatic mode will not attempt to connect the Core to the Cloud automatically.

http://docs.spark.io/firmware/#advanced-system-modes

So you need to put Spark.connect() in setup to get it to connect.

kennethlimcp · August 27, 2014, 11:54am

I wrote a code to connect like @markopraakli by my core keeps blinking green forever

Update

Alright so let’s ignore my code. I got it working now (somehow). I just tested OTA in SEMI_AUTOMATIC and it’s flashing well now as we speak.

Will jump over to MANUAL next

mdma · August 27, 2014, 11:57am

Try dropping the Wifi calls - they shouldn’t be needed and could be interfering. (I agree this code should work as is, and that the extra calls to Wifi should have no effect if not needed.)

kennethlimcp · August 27, 2014, 12:41pm

I uncommented this to let SPARK_WLAN_Loop() handle Spark.process() instead and was able to perform OTA flashing successfully.

Seems like some flags are not being set in Spark.process()? Just my wild guess.

github.com

particle-iot/firmware/blob/1f5ceefc5f077c0b2926db7b6ff93140a1d7e881/src/spark_wlan.cpp

/**
 ******************************************************************************
 * @file    spark_wiring_wlan.cpp
 * @author  Satish Nair and Zachary Crockett
 * @version V1.0.0
 * @date    13-March-2013
 * @brief   
 ******************************************************************************
  Copyright (c) 2013 Spark Labs, Inc.  All rights reserved.

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation, either
  version 3 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.

This file has been truncated. show original

I tried the following but it didn’t work as well:

SPARK_WLAN_Loop();
Spark.process();

@mdma, i have found the issue

Due to that new IF condition (for the case of MANUAL, during an OTA update, Spark.process() is not executed just before OTA update.

See: https://github.com/spark/core-firmware/blob/c8fa2e0b79f9792f6dc9a6bd07697ca300cee9bc/src/spark_wiring.cpp#L666

I added a Spark.process() after the line and tada! OTA

mdma · August 27, 2014, 12:55pm

Nice! I am repeatedly clicking the “like” button, sadly discourse will only give one like!

@zachary has been working in this area recently so he might be interested in looking at the fix.

kennethlimcp · August 27, 2014, 12:58pm

I think there’s more cleaning up than it looks though…

But it’s probably due to my poor understanding of the entire firmware for OTA flashing.

The SPARK_FLASH_UPDATE flag gets set to 0 in the Spark.process() function though OTA is happening. I wonder what’s the rationale…

stevespark · August 27, 2014, 8:28pm

I have used all three modes and found some minor issues that appear to have been resolved. I initially used the MANUAL mode and called “Spark.process()” every second or so in my main loop. However, when I tried to Spark.connect() I had the breathing cyan led but no connection. It was fine for working on a local network but to synchronise the time I had to download a Unix timestamp over the local TCP IP connection as I couldn’t use Spark.syncTime();

Next, I started using SEMI_AUTOMATIC mode and this was perfect for my code, allowing it to work on a local network and then calling Spark.connect() when required to download new firmware or to use Spark cloud functionality such as Spark.variable and Spark.syncTime. However, I had to call Spark.process() regularly in my main loop - this is not made clear in the documentation.

AUTOMATIC mode took care of everything but I prefer the above SEMI_AUTOMATIC to minimise any critical timing issues.

Overall I would say this functionality is a great step forward for those of us who want to dip in and out of the Cloud.

zachary · August 28, 2014, 5:48pm

Thanks @kennethlimcp! Please submit a pull request to core-firmware. In order to avoid calling Spark.process() in MANUAL mode without the user’s consent, I think you’ll need to wrap the call to Spark.process() in if (SPARK_FLASH_UPDATE). See these two functions which set and reset it to indicate that OTA is in progress.

kennethlimcp · August 28, 2014, 11:59pm

@zachary, just an update that i’m still working on this issue. I believe the issue is more than just Spark.process() not being called.

I’m debugging and nothing it Spark.process() gets executed as the conditions defined are not met to qualify for the variables to be set.

Gonna dig further.

The last DEBUG message i read before the solid magenta occurs is:

0000154508:<DEBUG> void SPARK_WLAN_Loop() (373):
SPARK_CLOUD_SOCKETED=1
SPARK_CLOUD_CONNECTED=1
SPARK_FLASH_UPDATE=1
SPARK_LED_FADE=1

We might probably need to review the SYSTEM_MODE code as i tried to force the error using AUTOMATIC with the same condition as how MANUAL behaves and OTA flash still worked fine!

markopraakli · August 29, 2014, 7:11am

Seems like I found a nice bug regarding MANUAL and OTA updates (glad to help you)
Do you guys have ETA to fix this?

sej7278 · August 30, 2014, 3:02pm

so static ip with no cloud used to be this:

#include "spark_disable_cloud.h"

unsigned long pucSubnetMask[1] = {0x00ffffff};
unsigned long pucIP_Addr[1] = {0x2a00a8c0};
unsigned long pucIP_DefaultGWAddr[1] = {0xfe00a8c0};
unsigned long pucDNS[1] = {0x08080808};

netapp_dhcp(pucIP_Addr, pucSubnetMask, pucIP_DefaultGWAddr, pucDNS);   
wlan_stop();
delay(200);
wlan_start(0);

but is now this:

SYSTEM_MODE(MANUAL);

unsigned long pucSubnetMask[1] = {0x00ffffff};
unsigned long pucIP_Addr[1] = {0x2a00a8c0};
unsigned long pucIP_DefaultGWAddr[1] = {0xfe00a8c0};
unsigned long pucDNS[1] = {0x08080808};

WiFi.on();
WiFi.disconnect();
netapp_dhcp(pucIP_Addr, pucSubnetMask, pucIP_DefaultGWAddr, pucDNS);   
delay(200);
WiFi.connect();

Or static IP with cloud is:

SYSTEM_MODE(SEMI_AUTOMATIC);

unsigned long pucSubnetMask[1] = {0x00ffffff};
unsigned long pucIP_Addr[1] = {0x2a00a8c0};
unsigned long pucIP_DefaultGWAddr[1] = {0xfe00a8c0};
unsigned long pucDNS[1] = {0x08080808};

WiFi.on();
WiFi.disconnect();
netapp_dhcp(pucIP_Addr, pucSubnetMask, pucIP_DefaultGWAddr, pucDNS);   
delay(200);
WiFi.connect();
Spark.connect();

see also here

mdma · September 1, 2014, 3:33am

In the long run, imagine static IP support will be baked into the firmware as part of the wifi setup, since the call to netapp_dhcp() is persisted in the cc3000 eeprom. (This same fix also overlaps with enabling the 11-13 channels, since that is also persisted data and set as part of wifi setup.)

Mil · September 4, 2014, 2:11am

Hello everybody !

I’m actually trying to :

run my Spark on a local network (i.e. connecting it to a local Access Point, without connecting it to the Cloud because it will be used in a place where no connection to the internet is available)
provide the SSID of my local Access Point directly in the code

By reading all the topics on the subject from last March, I’ve understood that the use of #include spark_disable_wlan.h, #include "spark_disable_cloud.h and #undef SPARK_WLAN_ENABLE have been more or less deprecated. So I’m trying to do it with the WiFi and Spark classes,

I’ve tried to do this by putting SYSTEM_MODE(SEMI_AUTOMATIC); at the top of my code, then this in the setup() function :

if (WiFi.hasCredentials()) {
WiFi.clearCredentials();
}
WiFi.setCredentials(MY_AP_SSID, MY_AP_PASSWORD, WPA2);
WiFi.on();
if (!WiFi.ready()) {
    WiFi.connect();
}
Udp.begin(8888);

but it doesn’t work… I can’t manage to get the LED breathing cyan, informing me that the connection has been successfull.

Can anybody explain me why my code doesn’t allow my Spark to connect to my local Access Point ?

Thanks !

(PS : I’m compiling my code with the latest firmware and gcc by using the DFU mode)

maxint · September 4, 2014, 1:41pm

What colors is your led showing now?

In my understanding SYSTEM_MODE(SEMI_AUTOMATIC) is all off the automatic mode stuff, except for the Spark.connect() call. After obtaining a working Wifi connection, your led should breath green, not cyan.
I can imagine that for setting the credentials manually, MANUAL mode would be more suitable, requiring you to setup the connection yourself. Have you tried that to see how that works out for you?