This came up on kickstarted recently. There was a previous thread on this which I can’t find.
Specs are certainly good, it was well backed and they seem on time to deliver so should be able to order retail in April. As it exceeded all stretch goals all the components will ship with a nice unibody case.
Deancs, I pledged for the logic analyzer since I already have a scope. I like the open source nature do the project. The should be shipping by end March. :
Sure, we’ll take lots of pictures 
I’ll have my 4 months exchange there next year and would be so awesome to meet you again there in future 
Speaking of affordable scopes … and signal generators and high speed data analysers, for anyone interested … I am really looking forward to getting hold of a Red Pitaya.
Stumbled on their Kickstarter (I think?) a month or so back. It took a while to figure out exactly what the thing was and what made it special, but now that I have, it looks yummy, for the price.
No reason this could not operate as logic analyser as well, via the FPGA connected digital inputs. It probably already has an app (Android/iPad, etc) for that. Check it out.
b.t.w. I’ve contacted DSLogic analyser mentioned by @deancs https://www.kickstarter.com/projects/dreamsourcelab/dslogic-multifunction-instruments-for-everyone/
They are taking preorders with PayPal. Just write them a private message on Kickstarter. They are preparing for shipping already.
Just finished looking properly at the DSlogic. Looking good alright. Price is excellent, for what you get.
What I liked about the Red Pitaya, though I don’t think it has quite as good logic analyser specs(?) is that they have tablet apps for driving it. So, one can use the likes of an iPad (mini) as the main user interface, thus taking up much less space on the workbench. If DSlogic do that as well, it will make for a really nice piece of kit.
gruvin, have you seen thist:
Because of this competitor, DSLogic said that developing a mobile app is on their todo list.
These affordable scopes look really cool and full featured.
I’m glad the price on this type of equipment is plummeting so when it comes time when I need one I can get one at the new revolutionary price point.
The Red Piyata looks the coolest out of all of them.
Cool.
The Red Pitaya platform has a number of mobile device user interfaces, too. Unfortunately however, the Red Pitaya sales team appear to have opted for some weirdo, old school 1950's style, "tell them only bits and bobs and keep everyone guessing" B.S. marketing scheme. So finding anything online or getting any real clarity about the product is painful. All I can say is that I have seen apps for oscilloscope, spectrum and logic analysers ... but I cannot find so much as a screenshot today. Thumbs down from me to all that nonsense.
Luckily, there appear to be several other great options also available. So thanks again!
That said, why is that almost no digital 'scope manufacturer ever wants to confess what their sample resolution is, unless it's 14-bit or more?
I while back, I purchased a $1,200 digital scope but was dismayed to find how useless 8-bit sampling is. Apart from the horrible fuzzy display, there's insufficient dynamic range for any serious work. I sold the thing in disgust.
I cannot find anything about the SmartScope concerning its sample resolution. I fear it may also be only 8-bit. (The Red Pitaya is 14-bit ... though for the same reasons mentioned above, I cannot find reference to that today, either.) It seems the 'scope add-on for the DSlogic might be 12-bit. But they don't say. I have asked the question and will report back.
I finally heard back from DSlogic. Their oscilloscope add-on has only 8-bit resolution. :’(
That makes it pretty hopeless, certainly for my needs. Clearly, an 8-bit digital oscilloscope is better than no 'scope at all and I guess a fun toy to play with. But it will be far worse than a cheap second hand analogue scope. So I won’t be buying one, that’s for sure.
So for me, it’s back to try and decipher the Red Pitaya mystery marketing half-information that their obscure website kind of almost presents. What the fek that’s about, I just can’t say. It’s like they don’t actually want the thing to become popular or known about – or something. But the specs I have been able to glean from it so far (mostly the original Kickstarter) do suggest that it’s the best offering out there, in terms of price/performance and overall flexibility. So I shall persist.
Hi #satishgn,
Sorry for my ignorance, but for some reason when I include “spark_disable_cloud.h” in the applicaiton.cpp
the ip, subnetmask and etc have a value of 0.0.0.0.
Note that I actually can see the core is connected to my router and I can communicate with it.
[EDIT]
I figured it out,
just before getting the ip info, if I call:
netapp_ipconfig(&ip_config);
seems to be fixing the 0.0.0.0 ip .
Is there another way of getting the ip address of the core?
Thanks,
/N
This works great, but still there is one problem.
For example if I execute the program in the loop but at some point lose connection to the cloud, then the until they be connected again with cloud, execution of the program will be blocked. How to avoid this?
Are you connecting with the cloud can be with non-blocking function?
Example:
#include "application.h"
#include "spark_disable_wlan.h"
#include "spark_disable_cloud.h"
void task()
{
//Indicates user loop running
digitalWrite(D7, HIGH);
delay(100);
digitalWrite(D7, LOW);
delay(100);
}
void setup() {
WiFi.off();
Spark.disconnect();
pinMode(D7, OUTPUT);
Serial.begin(9600); // open serial over USB
WiFi.on();
Spark.connect();
}
void loop()
{
task(); // if lost conections with the cloud this code is blocked!
}
This is a problem if you have a function that should be run continuously even when not connected to the cloud!
Hi @NaAl, this seems to be a bug in main.cpp. With cloud disabled, netapp_ipconfig(&ip_config); is not executed because of false if() clause. I am filing an issue in github. easy to fix. Thanks for pointing this out. Temporary you can call netapp_ipconfig(&ip_config) to bypass the problem.
Issue created: https://github.com/spark/core-firmware/issues/168
@NaAl, the following commit should fix the ip_config issue: https://github.com/spark/core-firmware/commit/48b88d209b3681f17bf4325e7fc64f4af2a3f369
I’m running into a similar problem. I’m trying to both conserve battery life and utilize the Spark in an environment where it is not on the Internet. I’m utilizing the WiFi.on() and WiFi.off() as recommended, but it seems that when I turn WiFi.on() it still tries to get an IP address and if it is unsuccessful (e.g. outside the lab) it will continue to blink green and stop all other functionality. Further, if it does find an IP address (e.g. in the lab) it will breathe green and ignore the WiFi.off() command.
Using the previous example:
#include "application.h"
#include "spark_disable_wlan.h"
#include "spark_disable_cloud.h"
void task()
{
//Indicates user loop running
digitalWrite(D7, HIGH);
delay(100);
digitalWrite(D7, LOW);
delay(100);
}
void setup() {
Spark.disconnect();
WiFi.off();
Serial.println("Here we go...");
pinMode(D7, OUTPUT);
Serial.begin(9600); // open serial over USB
}
void loop()
{
WiFi.on(); //starts flashing green
task(); //will execute the task while still
//flashing green, but...
//if it cannot get on the Internet, all stops
WiFi.off(); //once it breathes green it
//ignores this command OR it crashes.
}
Any thoughts or help you could provide would be greatly welcome. Thanks!
gcoffee, I was playing with several configurations of a project looking at ways to conserve energy. One was with the WiFi.on()/off() pair. The thing you have to be mindful of is that issuing the WiFi.on() command only sets a flag and the actual action takes place in the SPARK_WLAN_Loop(). So when you issue a WiFi.on() you need to wait for the command to complete using WiFi.status(), which will return WIFI_OFF, WIFI_ON or WIFI_CONNECTING. The same applies to WiFi.off().
If you do a WiFi.on() then it WILL try and get an IP since that is the purpose of the function! Perhaps using a timer and WiFi.status() so if it does not connect within a certain time, you do something else. Make sure in the timing loop you keep calling SPARK_WLAN_Loop() or it will stall.
One thing I noticed in your code above is that at the end of the loop, you call WiFi.off() (without waiting for it to be really off) and then loop to WiFi.on() again.
Another way to turn off WiFi is to use Spark.sleep() which does not really sleep the processor, only the CC3000. It basically does WiFi.off() but for a specified number of seconds.
In review, here is how I would modify your loop():
void loop()
{
WiFi.on(); //starts flashing green
int i = 0;
while ((WiFi.status() != WIFI_CONNECTED) && (i < 500) { // Loop until connected or 5000ms
delay(10); // This actually calls SPARK_WLAN_Loop() during the delay!
i++;
}
if (i >= 500)
CONNECT TIMEOUT - do whatever
task(); //will execute the task while still
//flashing green, but...
//if it cannot get on the Internet, all stops
WiFi.off(); //once it breathes green it
//ignores this command OR it crashes.
int i = 0;
while ((WiFi.status() != WIFI_OFF) && (i < 500) { // Loop until connected or 5000ms
delay(10); // This actually calls SPARK_WLAN_Loop() during the delay!
i++;
}
if (i >= 500)
DISCONENCT TIMEOUT - do whatever
delay? Otherwise you are essentially keeping the WiFi ON almost all the time!
}peekay123 – Thank you for your feedback. I really like the Spark Core and I appreciate how much work you all have put into it and the support you provide to the community.
Regarding this issue, I don’t think I’m communicating my problem appropriately. In my project, I’m trying to utilize the Spark Core in an environment where it is NOT connecting to WiFi. I’d like to turn on the CC3000, do a quick look at available SSIDs, and then turn it back off again. I don’t need it to get an IP address or connect to the Internet. Is there something I can do to make the Spark Core work in that fashion?
gcoffee, the trick is in how the CC3000 works. When you initially get the Spark and register it, you created a connection profile on the CC3000. Several profiles can be stored in the CC3000 and I believe you can create a profile within the code. As for scanning for available wifi, Dave (Spark Team) posted this on one of the topics:
If a stored profile matching an active wifi is found, the Spark will attempt to connect to it when you turn on the wifi. You could, in theory, keep wifi credentials for known SSIDs and manually connect to each when you detect them. I am guessing on the manual connection part and @Dave may know more. Also @timb could help you. I just haven't dug into that part of the code yet! 
Hi @gcoffee,
Ahh, sure, you can include #include "spark_disable_cloud.h" at the top of your code, and it should prevent connecting to the internet. There was some work done to try and make this easier, details here : https://github.com/spark/core-firmware/commit/0a0840692ed84c8d449e3ea5f9edf2d231186582
Thanks!
David