Skip to content

Troubleshooting

The following sections offer a troubleshooting checklist for problems that developers may experience while working with the NeuroScale Platform.

My instance has not launched after more than 2 minutes

After more than 2 minutes in configuring state you can be sure that your instance did not launch correctly. Most likely this is due to an issue with the launch parameters that you used, but in rare cases there can also be an issue with the pipeline itself, especially in the case of beta pipelines. To troubleshoot, try to use one of the example clients to launch an instance of the desired pipeline (for pipelines that produce a single-channel measure, use the client_concentration_lsl example, for pipelines that produce as many channels as you streamed up, use the client_lsl example). To use the LSL clients, you may need to play back some data for them to stream up, which is explained in another document. If these clients succeed, you know that there is a problem with the launch parameters you passed in; if so, carefully compare the JSON-encoded request body that is being generated by your code versus the example client. If an instance of the desired pipeline fails to launch even with an example client, contact support@neuroscale.io and we will resolve the issue with you.

I am not receiving any data in return

This can have multiple causes that should be checked one by one:

  • Can you receive your own MQTT messages back when subscribing to the topic on which you publish with another client (e.g. MQTTlens for Google Chrome)?

  • Do the stream names in the Instance Metadata match the names in the messages you send up?

  • Do the topics that you publish on/subscribe to match the input/output nodes defined by the Instance Metadata (pipelines used to create an instance usually have at least a "default" input/output node)?

  • Does the number of channel labels you declared match the number of channels in your messages?

  • Do you have duplicate channel labels?

  • If sending multiple streams, does the same happen when sending only the minimal number of streams?

  • Does the number of output channels that you declare correspond to the actual number of channels produced by the instance (usually either 1 or as many channels as you streamed up)? Check the documentation for the pipeline used to create the instance for details on what output channels are produced.

  • Is the instance state going back to configuring after you send your packets?

  • Are you transmitting nan or inf values?

  • Are some of your channels flat-lines or short-circuited (i.e. identical signals on both)? This can be checked by temporarily removing potentially problematic channels (note that most pipelines deal with such channels appropriately).

  • Are you using a pipeline with artifact removal (e.g. ASR) or another adaptive filter, or does the pipeline document that there is an initial processing delay? If so, you may have to wait up to 60 seconds (see pipeline documentation for the exact amount) until the instance has calibrated itself.

If none of these are the issue, the next thing to check is if the instance state goes back from running to configuring; if so, go to the section entitled "My instance goes back to configuring state after I start sending messages" below.

My instance goes back to configuring state after I start sending messages

If this happens then an error occurred in response to the data you sent up; this is either due to the number of channels not matching what you declared in the metadata, or your channel labels having duplicates, or due to an error deeper in the instance (perhaps even in the pipeline used to create the instance). Contact support@neuroscale.io for help resolving the issue.

I am getting disconnected from the MQTT broker after a short while

This can happen if you are not fetching messages fast enough on the topics that you subscribed to or if you are sending more messages per second than the instance is picking up. Once the broker has to buffer up more messages for you than its capacity limit, it will disconnect you. To fix this problem, make sure that you send fewer larger data chunks (e.g. 10 to 20 per second), and make sure that your MQTT message polling code is picking up all new messages per each loop cycle, instead of one message every fixed number of miliseconds, especially when you subscribe to more topics/nodes than one.

The return stream is "hitching" occasionally

Hitches (i.e. temporary data holdups) are usually caused by the network between you and the cloud. To mitigate these issues, see the section entitled "Minimizing latency" in our Best Practices guide. If these measures do not resolve the problem and your application is not latency-sensitive, a good strategy is to have a buffer of n seconds (or miliseconds) of pipeline output; whenever this buffer is empty, wait until full, and then start displaying (or otherwise handling) the data from the beginning of the buffer in real-time (similar to how YouTube, for example, pre-buffers data to ensure smooth playback).

The return stream is stalling for a few milliseconds at a fairly regular interval

If this happens, there is an interference between the rate at which you or your hardware is streaming out packets, the rate at which you display the pipeline return values, and potentially the rate at which the instance itself is picking up messages. First you will want to ensure that the rate at which you're displaying processed outputs (e.g. in a visualization) is an integer multiple of the rate at which you are emitting raw data messages (e.g. 15/60 or 20/60 Hz). It is worth checking if this is really the case since the timing of update and display refresh cycles can be unreliable. Once this is ensured, consult on the update rate of the pipeline (which is either documented or support can tell you); unless the update rate is very high (>100 Hz), make sure that it is an integer multiple of your data sending rate and integer multiple/divide of your display rate. Support can work with you to generate a pipeline that has the right update rate. Contact support@neuroscale.io for further details.

Troubleshooting your Pipeline Configuration

'Error' status when setting up a Task

Task setup failures are commonly caused by an incorrect filename, unexpected channel names, or any other unexpected parameter values entered upon Task Creation.