Guys, we updated the Blynk Spark library to v0.1.8.
We noticed some strange behaviour of Blynk on Spark Core.
When trying to do “virtualWrite” on 10 pins 2 times a second (so sending approximately 20 values/second), it works really slow and sometimes connection drops. Same scenario works perfectly on Arduino UNO + Ethernet shield.
I think it may be something specific about TCPClient that we don’t know. Could someone help to deal with this?
@harrisonhjones, could you please help us to understand what’s wrong?
Thanks
Are you reading all the data returned to the core in your connection? You cannot depend on flush() to clear out the data since that only clears the TCPClient buffer and not any remaining packet buffers inside the TI WiFi chip.
On the old library it sometimes it goes for ages without issue and other times I get the cyan flash. I should have some time today to play with v0.1.8 and see how it goes.
Maybe it’s blocking the heartbeat of the cloud connection or something.
@bko, we don’t use the flush function… i thought it’s flushing rx buffer, like in Arduino.
Anyway, I have prepared a python script (server) and a sketch (client) which show the problem. They are located here:
(Note, that these do not use the Blynk library, just the Spark API to understand the flow)
Just flash EchoSparkCore example (you’ll have to set server ip to your local PC),
and run python server (tcp-echo-test.py):
python ./tcp-echo-test.py --sleep=0.1 --qty=1000 --port=8282
This will send 1000 messages with 100ms delay, and wait for all responses.
You can specify more connection parameters (use --help).
It also visualizes communication process:
python ./tcp-echo-test.py --sleep=0.1 --qty=1000 --port=8282
[ 0.000] Listening on port 8282
[ 0.516] Connection from 192.168.0.102:2278
.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v..vv.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v
.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v.v...v..................
........................................................................................................................
................
. - sent
v - received
So you can see that after some time we stop receiving data.
The sketch prints debug info.
With a bigger delay, there seems to be less problems.
BTW, Arduino UNO + Ethernet shield handles approx. 300 messages/sec.
Could you please take a look?
Maybe some API is misused…
Hi @vhymanskyy
Yes, flush is for the RX data to the core but it is not sufficient since data is buffered in two places.
Your sketch does not seem to allow for the cloud when the connection stays connected. How do you intended this to work? Is the server side closing the connection? If you expect to spend a lot of time in the while connected loop, then the cloud connection will timeout and restart your core causing problems.
Maybe you want to try with the Spark cloud off using manual mode.
Hi. Thanks for fast response.
It just fetches and prints available data, and then send it back.
I’m calling Spark.process() on line 43. I think this should be sufficient to allow WiFi/Cloud stacks to do their job.
Any suggestions? Do I need to call Spark.process() elsewhere?
I would recommend to run the script to see the live behaviour.
I recommend you try it in manual mode since your while loop is blocking.
[EDIT] Or you can change you Spark.process() call to SPARK_WLAN_Loop() inside the while loop.
One more thing jumps out after a second look:
for (int i=0; i<qty; ++i) {
client.write(buf[i]);
draw('.');
}
This sends one packet per character in buf[]. A better way would be more like this:
client.write((uint8_t *)buf,qty);
@vhymanskyy have you tried looking at the data with wireshark and comparing to an arduino with cc3k shield? like @bko said it will send each write one at a time just like the client.print which has the same known problem you are seeing.
what does the core print when you run the code?
If i finish work at a reasonable time tonight ill have a go myself running the python script and seeing what i get.
@vhymanskyy i am having trouble running the python script, i get the following error… any ideas?
edit: I got it working, i was still on python 2.6 and had to change the print format to suit. i got it to run briefly and only managed 8 returned messages before the core dropped its cloud connection. but i also noticed the core was struggling to keep it before that because my internet is so slow at work. one other thing to note I had to change my firewall to accept the incoming connection, it worked once then after that my core could not connect again. tonight ill try again. I’ve just updated pyhton to 2.7 so ill see how i go with that.
C:\Spark>python tcp-echo-test.py --sleep=0.1 --qty=1000 --port=8282
Traceback (most recent call last):
File "tcp-echo-test.py", line 142, in <module>
log('Listening on port %d' % PORT)
File "tcp-echo-test.py", line 78, in log
print "[{:7.3f}] {:}".format(float(time.time() - start_time), msg)
ValueError: zero length field name in format
@Hootie81 thanks for looking into it… didn’t check with python 2.6.
You can try with a longer sleep, to see that it’s actually working with 1 second delay.
@bko, I tried your suggestions, but I was getting spark failure (red light flashes) when using write(buf, qty)…
This is strange, as actual implementation in Blynk library uses this call.
Still investigating it…
Just playing with this now too. Im seeing a red SOS and a single flash which is a hard fault and is common with tcp client. i have most of the time been able to fix it by ensuring the receive buffer is emptied properly without filling up
Im getting some really weird things happening like the core not connecting to the python script unless i ping the core. im sometimes getting 15 messages out and echoed back other times Im getting only one before the hard fault!
I’m also getting a red flash three times after flashing tinker the first time it starts after being flashed… i think its time for bed anyway!
@Hootie81, @vhymanskyy, has the tcp issues in Blynk for Spark been ironed out?
I ran out of time when I as testing it. I had so many problems with the cc3k and had to ping the core continuously to get anything to happen. Wireshark was very interesting to watch and there were some patterns forming when it crashed.
One thing I was going to try but didn’t was to run in manual mode. All crashes happened just after the keep alive or whatever the larger of the spark cloud transactions is. There was “spurious retransmissions” then it sos’s and restarts. Oh, then it takes a few more restarts and loads of pings to get anything besides connection failed.
The test setup above doesn’t use blynk servers or anything so anyone can try it. It really interesting to watch what it’s doing on Wireshark too
I have just received the latest blynk update. Looks pretty good. Looking forward to getting this one going. As I am in the UK will the app end up on the UK or Europe app store?
I especially like this:-
I know how that feels! 
To quote Simon Mayo and Mark Kermode on BBC radio 5’s flagship film review show -"How do you do snapchat? You just do snapchat? Followed by a series of comments like “how do I do ??? - You just do ???” insert Brain surgery, rocket science, publish a spark variable 
(one for you there @peekay123), etc…
This image is one of my favorite 
You should be able to download Blynk app from any store. We make no geographical limits.
Guys, by the way, Blynk is live in the AppStore and Google Play. You are very welcome to try it out!
I was playing with it last night, and I was impressed! I’m piecing some things together from the example code in the Github repo, since the full docs aren’t up yet, but I see a lot of potential here!
I have the app too. It looks great. I will have a play if I get chance. I might wait for the docs. Are they on the way? I could do with a numpty guide😄.