Cloud drops constantly, no TCPServer working, no hair left...many bumps on the road

Troubleshooting
1

I seemed to do well out of the gate, the Spark core is simple to initially setup (bonus!), and it is similar to arduino so I got this. The initial cloud drops i largely ignore, oh probably fixable, I carry on. My experience progressively get’s worse.

Main issues:
(1) connection to Cloud drops constantly. Sometimes it’s flashing blue (slow sometimes fast). Sometimes ping works during this time but often ping goes no-reply as well.
(2) TCPServer doesn’t work. At first nothing, then I figured out a conflict with TIMER2 and I got it to send something on initial connection but then nothing. It should send a sentence each second.
(3) Documentation is not complete. For example, what is the return value of functions in the API, not mention of return value ever. Does the function block or return right away? Such as server.available()…No idea. Figured this out to be non-blocking but pain point. Also no mention of what resources (timers, interrupts, etc) that each feature uses. (see #2)

At first I am impressed with how easy it is to get cloud communication working. I begin with variables and functions, then proceed to publish()…nice but it is fairly slow at max 1 update/sec but acceptable. However the cloud dropping quickly made my attempts at building a user interface to the spark unusable.

So I move on to TCPServer to make things local and fast! Nope. Can’t get that code to work at all. So for now I am totally busted!

I have a strong software and electronics/embedded background. Not a noob, except for spark specifically.

I just checked my Wifi with inSSIDer and I am on channel 11 with -44db rssi (both my android tablet and the spark read -44db), only 1 other overlapping wifi and he is at -96db so well below me. My wifi signal is very good.

Changed my LDO power suply to a switching one with >2amps to run the spark…definitely not a power issue. Added 330uF, 100uF and a 2.2uF cap to power rails…lots of capacitance!

Changed from a chip-antenna spark to a UFL one, around the same -44db rssi.

I was part of the kickstarter, so I have the first batch of boards. Are there firmware updates I need to be aware of? I saw one on the CC3000 that I will try. I’ve only used the webIDE so far, does it automatically update the core firmware on the spark?

My goal is to replace my Treadmill dashboard with a wireless interface as I am converting my Nordic treadmill into a walking workstation. I have a 27" monitor covering the existing dashboard so I can’t access it anyway. This was my way of putting my treadmill on a web page and being able to control it, as well as record my history - sessions, time, calories, miles, etc. I just ordered a heart-rate sensor and an ANT+ breakout to put on the Spark so I will receive heart-rate signals and record that as well, and also control tread speed to maintain a target heart-rate.

Thanks for taking the time to read my long post. I welcome any suggestions!! :smile:

I am trying to share my code but can’t figure that out either. How do I get my code out of webIDE other than cut and paste? I’d like to just link it to GitHub or the hackster.io.

Colin

1 Like
2

How are getting your data into the Spark. Is it serial or Digital/Analog IO? It is just that with the same code, if I have serial data going in, my Spark is less reliable on the Network. Stop the serial data with the same code running, and things are more reliable. Just a thought

Oh, there is also a patch to the CC3000 firmware that you can load in which will help too. Takes you up to 1.28 I think from memory.

Darryl

3

Hi @guru_florida,

Thank you for posting! We really appreciate the feedback, and improving the documentation is a big priority.

We’ve been working on a patch we’re calling “deep_update” that brings some major stability improvements to the CC3000 wifi module on the core. This patch is especially helpful on busy networks, or networks with lots of devices, since the problem seems to stem with how the CC3000 handles ARP traffic among other things. If you want, you can apply a dev version of this patch (I use it on my cores), but it requires installing a few things:

If you haven’t installed it, I recommend the spark-cli ( https://github.com/spark/spark-cli ), and dfu-util ( http://dfu-util.gnumonks.org/ )

If you’re on windows you’ll need some drivers, but on Mac and linux they’re ready to go: https://community.spark.io/t/tutorial-installing-dfu-driver-on-windows/3518

Once that’s all going:

1.) connect your core via usb

2.) hold down both buttons and release the reset button, keep holding until your core flashes yellow

3.) update your factory reset version:

spark flash --factory tinker

4.) run the patch

spark flash --usb cc3000

5.) once your core stops flashing purple, and starts flashing yellow again, reload tinker

spark flash --usb tinker

6.) Plug your wifi credentials back in with:

spark setup wifi

I hope that helps!

Thanks!
David

1 Like
4

Thanks Dave,

I already updated CC3000 with the git version but that didnt help. I followed your instructions and now I can’t ping although I can reach the device via cloud, so that tells me your upgrade worked since I read somewhere that ping is turned off in the deep version. It hasn’t seemed to make a difference. The play-by-play, it get’s connected and sends a few lines of updates then goes off again. It hung with nothing for a while, then netcat (nc) disconnected/exited, I tried nc again and it failed, then it connected, but I am not getting anything now. Another nc disconnect. Nc again and nothing. Try resetting. Works. I get connected again. Connected and streaming updates for about 8mins then no response from either TCP or cloud. Breathing cyan still going the whole time. Oh, after 2 mins of cloud timeout the cyan is blinking fast. After 3 mins status light is dark - nothing. After another 3 mins white pulse, then blinking green, then back to breathing cyan and connectivity back. Well I give up for now.

vk2ts: For now I have no data coming in. I don’t use serial at all. The most I do is some reading of pins. I do use 1 interrupt on A1 pin, and I use TIMER4 to generate an interval timer. The interval timer generates a 20Hz PWM. I would use built-in PWM but it doesn’t go below 380Hz apparently. Other than the interrupt (which is never hit right now) and TIMER4 I don’t do anything else.

Could some of my difficulty come from how disconnects are handled? Here is my TCP relevant code. Could it be temp related? The core get’s to about 60 degsC.

    //output our status as an event
    if(now > next_status_emit)
    {
        sprintf(status,"$%c%c%c:%d:%d:%d:%d:%d", 
            enabled?'E':'-', running?'R':'-', (incline_in_motion>0)?'I':(incline_in_motion<0)?'D':'-',
            speed, desired_speed, 0, config.current_incline, desired_incline
            );
        server.println(status);
        next_status_emit = now + (running ? 250 : 2500);
    }

[snip]

    if(client)
    {
        if(!client.connected())
            client.stop();
    } else if(client = server.available()) {
        delay(50);
        sprintf(status, "#TREAD:%d", firmwareVersion);
        client.println(status);
    }
5

FYI I got a server error on the forums here trying to post the above, offline for about 20 mins. I don’t know how you guys did it, but it recovered my text after the server came back online. Usually the post is lost after such an incident. I always copy to clipboard before posting on any forum just in case. Good job! :slight_smile:

1 Like
6

I guess if I was trying to solve this, I would be working out if the problem was being caused by an interaction on the input side, or on the network side.

I would be seeing if the PWM is the issue by disabling that if I could, and leave everything else the same. I would also try significantly reducing the update rate, and see how that affects things. This should tell you a lot about the nature of the problem.

My sparks are nowhere near 60C, at least to the touch, but it is winter here and I am guessing that it is about 18C here in my office.

1 Like
8

Hi @guru_florida,

Thanks for trying the patch! :slight_smile: Hmm, we discovered an issue on the core were a bad power supply / bad usb cable can cause the regulator on the core to heat up. Can you try a different USB cable / power supply? Otherwise would you feel like sharing your source and we could try to see if there is an issue there?

Thanks,
David

9

Hi vk2tds,

These are all good suggestions, I did try a few of them already. There is no input or interaction to the system right now, I have one spark bare - just the usb cable connected, I have another that is in-system. Both have the same behavior. When the spark powers up it starts generating status. Well, to be precise, it generates it if there is a connection, but the status loop runs on startup. There are no dependancies on input, it simply outputs the values of some variables each second during running or every 2.5secs when idle.

I did try disabling PWM for a while. That is how I discovered TCPClient/Server must be using timer1 because I got no data ever until I did that and subsequently moved my PWM to timer4. I will disable again though, it won’t hurt to get to the minimal functionality until this is fixed. I will also reduce the update rate, good idea, see if less data causes it to stay online longer.

Dave, interesting about the onboard LDO issue. I make the Quadrino Quadcopter Flight Controller and I would say 1 out of every 200 units has an LDO that will get hot. I’m not sure if a user somehow shocks the LDO into doing this or not. Hard to track down. Though the LDO gets warm it seems to be the CC3000 that generates the most heat. Not unexpected in Radio chipsets, it get’s as hot as my Venus GPS chip does when it is searching for satellites.

I am feeding in exactly 5v from a switcher, I could reduce this to 4v for less drop out, or unsolder the LDO and provide 3.3v directly. Thoughts? I have lots of capacitances on the rails. I also tried a 7805 type regulator with the same results. No usb cable connected on the in-system spark board. The second spark is just usb connected, either bare or sometimes connected to m scope/logic analyzer. That I use for initial development/testing and it has the same behavior.

So to recap, next I will try:
(1) Disabling all code except for the network communication loop.
(2) Reduce update rate.
(3) Get a source code zip ready.
(4) I will use Spark.disconnect() to disable the cloud and see if that helps stabilize TCPClient/Server

2 Likes
10

My guess is that this will significantly reduce the temperature of the device. More transmissions will mean that the power amplifier will be on more often. +18 dBm is a reasonable amount of energy that will need to be dissipated. That might explain the reason your devices are a lot warmer than mine.

If the LDO ends up being the problem, you might be able to put a reverse biased diode from the 3.V volt to 5V pins, and feed 3.3V in directly. This diode might protect the LDO regulator from the reverse bias. I have seen it in other designs, but have not looked to see if it will work in this case. This would allow you to have your design work without modifying the spark at all.

1 Like
11

I’ve modified the code so that when I connect directly using TCPServer/Client it disabled the cloud API. The breathing cyan LED switched to a breathing Green. Cool. I netcat to the spark and I get status updates once every 5 secs, and I can execute commands (it responds to my input). However, it still crashes anywhere between a few minutes to 15 mins, weather I am performing input or leave it alone. I get a bunch of blinking red lights before the spark resets but they are not regularly spaced red blinks so I can’t count them for sure, at least 3, but I think its around 5.

I also bought another Wifi router hoping that might be the answer but nope. I’ve made sure the computer is not going to sleep and I’ve tried 2 computers. I’ve added a (#define) SIMULATE mode to the code that disabled all non-essential code to test networking. (So no ISRs or timers are used). Reduced the update rate to 5 secs, and the sentence is only about 15 chars anyway.

Any suggestions?

I’ve submitted my code to GitHub. The project is here:

12

the red flashes will tell you what the issue is… its easiest to record it and watch it back a few times, there is a SOS then a code have a look at the docs page there is a good write up on it.

if your using the TCP stuff you will need to put small delays between each print… some people say 2ms some require 100ms try it out and see. there are 3 or 4 threads on this forum discussing it.

13

Ah, now I see, I was confused by the SOS signaling. So it is a single blink…code is HARD FAULT. What is that? Hardware fault? strange.

14

that sounds like the one people get when they don’t put delays in the TCP stuff

15

I have been meaning to suggest that someone implement this as an API function...

16

Does anyone have any luck using TCPServer and Spark Cloud functions without issues ?
I am still having problem to get both working at the same time.
Once I enable the TCPserver functions, all the Spark Cloud service will not able to perform.