Hey beta testers - if you guys are out there, would love your feedback! Post in this thread to share your progress. If you’re having any issues getting it up and running, we can help debug here.
I had some issues with iOS7, which was kind of a test, I find that most apps on iOS7 are still buggy.
Once I loaded the config with iOS6 I did get the unit to connect and used the api to toggle the LED, my wife thought I was crazy turning it on and off for like a half hour 
Only major bug so far is Wifi is dropping in and out like clockwork, about 60 second intervals, disconnects last about 5-10 seconds. This might be due to my wifi network which consists of an airport extreme wireless N rev 1 unit, extended by 2 airport express wireless N rev 2 boxes. I am wondering if it is trying to jump between access points or something?
I have seen some api requests that reported to receive the packet fine, but did not make it to my device. I have yet to determine if this is a side effect of the wifi disconnects, or not, need to write some test scripts to automate the requests so I can follow it easier.
Below is a photo of my core, much smaller in real life than I anticipated. So cool!
1 Like
Gorgeous picture! Thanks Anthony!
Saving some state (which pins are high and low, ongoing PWM rate, etc) to the cloud and restoring it on boot is not something we had discussed before, but is a great idea! It’s arguably better accomplished in the code that lives on the device, but we’ll definitely mull that one over. Our goal is always to provide the most intuitive user experience possible, and if saving state to the cloud can help, we’ll do it!
Regarding API responses—right now, the API service and the device service in the cloud do not block each other—it’s all asynchronous. The API saying “ok” currently means “I sent that message along (but I have no idea whether the device is listening).” We definitely have plans to implement a synchronous/blocking mode so the HTTP status code reflects whether the web resource (i.e., the Spark Core) was found or not. We have to balance speed/scalability with the obvious user expectation that “ok” means the device received a message, but we’ll find a happy medium there. I’d be curious to hear everyone’s thoughts on this.
hey,
ive got my spark unboxed and i have successfully gotten the TI SmartConfig working to connect the core to my wifi (it becomes pingable and LED2 is solid blue).
However, the LED1 light seems to continuously flash after the connection occurs.
I’ve tried this standing right next to my router.
Gonna run a wireshark and see what I find.
Curious what router you have?
netgear wnr3500v2 running Tomato firmware (WRT variant)
Any chance the beacons technique works?
http://processors.wiki.ti.com/index.php/CC3000_First_Time_Configuration_using_Beacons
1 Like
An API response of “ok” should definitely mean something more than just the API message was good. Ideally it should mean that the client device (Spark Core) received the message, however I can see that will take slightly longer to gather that data, which will slow down your API call rate. But if the Core cannot receive and acknowledge as fast as you are sending API calls, what good is that faster rate? An optional acknowledge response could be part of the message sent to the Core, to help lighten the load on the server by default. Maybe you would specify ‘ack:true’ or ‘ack:!0’ as part of your message to know for sure that it’s getting to your Core.
You raise a good point @BDub. I think it’s too late for them to change this version of the API.
I believe the thinking here was - like you said - to have low latency, as they cannot control what happens on the way across the Internet. I believe this could be resolved by implementing a callback system.
Too late? I don’t think so… doesn’t release officially until this fall time right? They are currently redesigning the hardware and beta testers just got the first batch and are working the bugs out. This is the perfect time to think of all the things the whole system should do, before 50,000 people have them and are banging away on the servers 
Callback system is nothing more than waiting for a response and when getting it, dishing it up to the function caller. That’s pretty standard in javascript and probably all single threaded runtime engines. If the server didn’t support this type of feedback out of the box, it would be possible to code it up in your application… but really since you have the POWER of that ARM processor, it really SHOULD be automatically handled for you transparently 
I really want to start working on something with the Spark Core! Can’t wait for it…
Oh ok. I’m very ignorant on this topic. I guess maybe incrementing the API version to a version that supports callbacks would be good enough. I was just thinking of backwards compatibility.
We’re going to make some pretty big changes to the API in the next couple of weeks, and we won’t be providing backwards compatibility; we’ll just deprecate the current API pretty much immediately. It’s awesome that people are starting to fiddle with the API but do be forewarned — it’s changing very soon! Such is life in this early beta phase 
I’d much prefer a callback, as opposed to hanging onto the request waiting for a response from the core.
@anthonywebb have you had any more luck tracking this down? I’ve been seeing similar issues, but I don’t believe my wifi is disconnecting, certainly not for 5-10 seconds. I just see some requests to toggle a digital output not reaching the Spark Core. This makes me want to definitely have a callback from the API that lets me know if my request was truly successful all the way to the Spark Core. I guess this is like UDP vs TCP, UDP is fast but does not ensure your data gets there (great for streaming audio), TCP is slower (not much) but makes sure your data gets there.
Is there a way we could send an API request tagged as UDP vs TCP, and once the Spark server gets it, it acks back that it’s “on it” and basically handles the request. If the Spark Core is already connected to the server in TCP mode, then I would almost think something is going on at the server that’s dropping requests after it acknowledges back to the requester. One step above all that and probably the slowest is getting a message back from the Spark Core that confirms the state of some variable, pin, function, etc… Shouldn’t a TCP connection be sufficient though?
Next subject. I know there are at least 10 beta testers out there and maybe more people like myself that have built up a spark core and are already fiddling. Some things I would really like to help test / work on are the SPI, TCPClient and TCPServer implementations. I would really like to start seeing what kind of speed I can get on the Spark Core for reading and writing data over TCP. So far I have been able to do this with Adafruit’s CC3000 breakout, but it’s very slow. For example, it can read a 49kB file in 168 seconds, vs. Arduino Ethernet shield 49kB file in 12 seconds. Both are too slow for my liking, but 168 seconds is ridiculously slow (< 300Bps). Theoretically the CC3000 can transfer data over TCP at 4Mbps (500KBps) if it has a decent processor behind it, and the STM32 Cortex-M3 definitely classifies as decent.
-
Can you tell us what speeds you are seeing for reading/writing over TCP?
-
Can we help test your library conversions as you are implementing them or is that even practical? For example, if you need to develop the TCPClient and TCPServer… if you do most of the Client first and push it out, we can start beating on it, or vice versa with the Server or SPI.
-
If we can help test things should we talk about them here or over in the issues list on core-firmware repo?
-
I want to work on getting Eclipse CDT installed and compiling the firmware, and I see some guides for this on the README.md of some of the other branches. Should this be all that I need to get up and running? I can compile firmware from the command line already, but this obviously is a terrible way to code and debug a complex system.
@BDub Don’t spend too much time debugging this, as we’re making some behind-the-scenes changes that will provide feedback on whether the Core heard your message and make these issues much easier to debug. These changes will also probably improve reliability of the connection.
Re: throughput of TCP, we expect that the beefier chip on the Spark Core and the fact that it uses DMA should make its throughput much faster than a CC3000 breakout paired with an Arduino. However, we haven’t gotten to testing this yet.
If you’re interested in helping us build/test on the firmware side, Github’s probably the best place to discuss. We haven’t had a chance yet to get to implementing TCPClient and TCPServer but if you’re interested in helping us get there faster and/or testing throughput, we’d love your help!
Re: Eclipse, getting it set up requires quite a bit of finagling with the settings to link everything correctly; I would personally recommend the command line compile instead, because the toolchain is already set up, especially if you’ve got it working already.
this is just an ack that I’m a beta tester and working a few scenarios … having issues with the CC3000 connecting and just started working on getting the command line tool chain working … having fun …
Is this the de-facto place for beta testers to submit comments, finds, etc.? Seems a little unlikely, as it’s two years old. Can someone point me to the correct location for people testing beta/under development builds? Or do I just post problems, etc. on the Github “Issues”?
This thread was probably for testers of the very first Cores, before they went into production. Those are beta hardware units. Any issues or troubles you may find can be posted either here, or on the relevant GitHub if it’s a real ‘issue’. Generally, try asking questions on the forums, and when things tend to not work after that, GitHub is probably the place to be.
I’m assuming that refers to the new Core firmware which you’re trying to build, rather than actual hardware?
I assume this comment is still true:
1 Like