Here’s mine. Not terribly different I’m guessing from yours, but worth a check if you’re interested:
Adding a delay in
setup() to allow
Spark.process() to run fixed the issue on firmware uploads. I get a feeling, though, that this is probably symptomatic of other bugs elsewhere in my code – I occasionally got hard-fault SOS codes while making uploads before doing this.
Been drilling down further into LAB’s spacebrew-arduino library, and here’s are my notes:
The spacebrew server pings are providing the biggest hints for me in finding the root cause. I set up my spacebrew server to ping at default 1 second intervals. Upon startup of the Spark core, the websocket (TCPClient) correctly responds to the server’s ping opcode without issue, and sends a pong opcode in response (sidenote: I do not understand why the library sends a 0x8A byte, given that the websocket specification mentions 0x0A – and 0x0A does not work).
Most critically, when the ping/pongs are going nicely, I’ll send a spacebrew JSON message out from my Spark Core. This works very intermittently, and works only when I send the data out very sporadically. Most of the time, it causes my Spark Core to cease serial output from all debug points in my
WebSocketClient::monitor function. About ten seconds later, the Spark Core resumes operation (cloud connection still good, TCPClient (websocket) connection to my spacebrew server still allegedly good), but the pings from my spacebrew server are no longer reaching the spark core.
I am testing using boolean and range data types to my spacebrew server. Event-triggered sends work, but not streamed data (it hangs up after the first/second send).
Whenever these hangs happen, my spacebrew admin page subsequently drops the Spark Core from the list of publishers/subscribers in it’s next refresh cycle.
To me, it’s either:
- my spacebrew server received malformed websocket data, causing a panic on the spacebrew end? Thing is, I did not notice anything odd in my spacebrew logs.
- could there have been a bug in the spacebrew server code, or just some incompatibilities in the websocket library that’s messing up the communication?
The still-impressive spark core and the easy-to-use (and jam) spacebrew interface is what made me want to attempt integrating these two together, but it’s been quite frustrating. It’s great to see someone else in the community trying this
(and yes, I am definitely moving into local USB flashing as I’ve pretty much had it with the long waits between each test)