ERROR:PACKET TOO LONG

[ghost]

I get this error after running the serial monitor for a few minutes every time.

[steeph-k]

I'm not sure if this is actually a problem or if there is a mistake in how the the packet length is tested. Nearly everybody seems to get this error. But the data seems to be correct. You can remove the line of code that outputs the error message and get a clean output of data.

[kitschpatrol]

Hi @JasonAlex and @steeph-k , thanks for writing. A few other people have reported this, so it's definitely an issue... I haven't had a chance to look yet but I suspect it's a parsing error and not an actual problem with the hardware. It doesn't seem to affect the data.

[Charios01]

This and the other error I get mostly when moving or touching mindflex or arduino, as I wrote to entertaillion. Ever when connection is nott really good, you get more of this errors. Are you using BT modul or Optokoppler for galvanic separation?

[zombodotcom]

Hey, I got a mindflex duel, so 2 headsets, I'm only testing one headset so far, I turn the headset on and I can get data for a few seconds on the braingrapher with an arduino, then I'm getting 200,0,0 some other guy had the same question and I asked him on twitter with one question and he blocked me for some reason? I get a few seconds of data every time I turn it on and off again then it cuts out to 200,0,0

Any ideas ? I'll try the other headset when I have time

[iiyeo]

Hi @kitschpatrol @JasonAlex Have you ever fixed it? I am getting this error and the checksum error most of the time. In rare cases, I could get the right raw brainwave data. Is there any solution to fix it? Thanks a lot in advance.

[ghost]

hi @kitschpatrol @JasonAlex
have you fixed this? Because i m getting this problem a lot of times. thanks

[kitschpatrol]

I haven't been able to reproduce this, and don't have time to go particularly deep at the moment.

Pull requests are welcome!

[zombodotcom]

I forgot if I fixed it or not, but I think it was the batteries, make sure you have new/charged batteries. I would have to retest this in the next few days to see if that was the problem. Or this problem was never fixed and I gave up on the project, I forgot

[ghost]

Hi eric Thanks for the answer I 've already substituted the battery and the problem persists. I 'm waiting your answer and i hope you manage to solve it. Mattia

[zombodotcom]

I read somewhere that it might be a grounding issue. It gets the values for about 5 seconds on the braingraph then cuts out, when I restart the mindflex it works for 5 seconds then 200,0,0

I think I just gave up on the project. I read somewhere that you should try and do it without the usb cable plugged into the PC but then you wont get serial. Maybe test with bluetooth.

Good luck

[ghost]

I ll try it Thanks Mattia

Il 09 feb 2018 03:21, "zombodotcom" [email protected] ha scritto:

I read somewhere that it might be a grounding issue. It gets the values for about 5 seconds on the braingraph then cuts out, when I restart the mindflex it works for 5 seconds then 200,0,0

I think I just gave up on the project. I read somewhere that you should try and do it without the usb cable plugged into the PC but then you wont get serial. Maybe test with bluetooth.

Good luck

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kitschpatrol/Brain/issues/8#issuecomment-364315231, or mute the thread https://github.com/notifications/unsubscribe-auth/AijWFOBxU9pP2aAJgcatgG1phOMukcGHks5tS6usgaJpZM4Bnrvm .

[JimRoskind]

[Before commenting: We wanted to say thanks for writing this code, and the discussion in the associated instructables!!!]

We had similar problems with the code, and debugged what was at least our issue. YMMV.

The fundamental problem that we saw was thet data arrives asynchronously, and almost continuously, from the Neurosky device. As a result, you MUST update() (read from Serial input) very often, and NOT block/pause in the loop() code between those updates. IF you do pause, then the Serial input buffer will fill, and bytes will be dropped/lost, corrupting the data stream.

The most common cause for blocking is trying to output (too much) data too quickly. For instance, a few calls to Serial.print() can wreak havoc.

The problem is that both the input stream and output stream use buffers, and once you fill the output buffer (with printed material!) the print() call will block, and wait until the buffer is low enough that it can accept the new data. In the meantime, data continues to arrive at the input, until the input buffer is filled, and then input data (from Neurosky) is dropped.

The result of that data-loss (discarded bytes) is effectively corruption of the recieved input stream, and any of the many errors will start to accrue (checksum? invalid code? payload length error? etc.). Worse yet, IF you try to print out the error messages (further overloading the output bandwidth!), then you'll fall further behind, inducing more errors, etc. etc. That collopse is often called a "spiral of death."

We just re-implemented the code from scratch, using an Arduino UNO, and a ForceTrainer. The force trainer defaults to running its serial line at 57600 baud. With the Serial.available() buffer space limited to 63 bytes, we had (worst case) to do another Serial.read() pass every 10 ms, and we had to NEVER block on output.

To achieve those results, it was critical to use Serial.availableForWrite() to avoid EVER blocking on output, and of course we can't do "too much stuff" between the updates. The update (Serial.read()) code also needed to be optimized to exhaust the input buffer ASAP, and only return when the input buffer was empty (it is not sufficient to read a lone byte). It is also paramount that the update() code NEVER waste time trying to output (error messages?), and risk being blocked! All it can afford to do is count the errors (and it probably shouldn't do any dynamic storage allocation... but I'm not sure about allocator's latency).

To support output, functions that print() or write() must be designed with an eye towards cooperative multi-tasking. More specifically, functions must "chunk up" their outputting activities to be small enough that print() calls will never exceed the (pre-checked) availableForWrite() space.

When you do all those things, then you can run continuously, with no errors whatever. Using the Arduino Serial Plotter, we can even get a beautiful plot of the power bands etc. from the Star Wars Force Trainer. We implemented the a whole system from scratch with cooperative multitasking in mind over in:

https://github.com/JimRoskind/NeuroskyHacking/blob/master/README.md

We decided not to mess with C++ library code, as we'd expect the whole system to be modified at once if folks want to add additional features (re: cooperative multitasking needs to look at the system as a whole). We also looked into using a second serial port (re: software serial port), but its lack of buffering, and latency properties, proved problematic. Apologies in advance if our code is not the best as it was our first Arduino effort (though it is EXTENSIVELY commented for illustrative/educational purposes).

Thanks again for identifying this a project! It proved most interesting.

[kitschpatrol]

Thanks for the conversation and for the thorough investigation by @JimRoskind.

[JimRoskind]

I'm very glad we could help! @kitschpatrol

Jim and Brianna