How to avoid packet losses (Cyton, Windows)
I use cyton.py to receive EEG data from Cyton.
It sometimes says 'Skipped AA bytes before start found', which describes data loss occurred I assume.
And it sometimes says 'ID: instead of ' ( lesser frequently )
How to avoid this message and capture all data certainly?
I hacked the USB dongle and Cyton board to a wired connection, not to use Bluetooth.
I use Windows 10, and set the COM port parameters as follows according to this page:
https://docs.openbci.com/docs/10Troubleshooting/OpenBCI_on_Windows
Latency timer (msec): 1
Receive (Bytes): 64
Transmit (Bytes): 64
The CPU is Core i5 2.7GHz. It is not so new, but fast enough to handle serial communication I think.
Comments
If most of the errors occur in the first second or so, they may just be during a synchronization phase, and you can just drop the first few seconds of data in that case. If errors continue beyond the start of recording, I would check the connection for problems, since a proper driver for your wired connection should not lose packets.
Errors occur even after a few minutes after the start of recording.
The driver version is 2.12.28 and is the current newest: https://www.ftdichip.com/Drivers/VCP.htm
The packet losses occur if I use Bluetooth wireless connection.
Hiroki, thanks. My impression is that you may have a faulty RFduino radio module on either the Cyton mainboard or the dongle. Nonetheless, some OpenBCI users are interested in the wired usb link, as shown on previous threads,
https://www.google.com/search?as_q=wired+usb&as_sitesearch=openbci.com
Can you mention any tips that you found for doing this with V3 firmware? Previous links showed it for V2. The features added by AJ to the V2 and later firmware actually make using the 2nd serial port on the PIC32 / chipKIT straightforward and not difficult. Are you using a usb isolator?
Regards, William
I would not be surprised about the errors under Bluetooth, since even under good conditions Bluetooth can certainly lose packets, and once a packet is lost the program will have to re-synchronize, giving you those messages.` I do think you need to check your wired connection for problems, though, if it does not stay free of such errors. A good non-Bluetooth driver should not error that way.
Actually, my collaborator ( electrical engineer ) did the hack.
He connected the dongle and Cyton board as shown in the image:
Actually I use about one and a half-meter shield cable to connect the dongle and Cyton.
The baud rate should be set as 115200 by cyton.py.
OK, interesting. I believe you may be leaving out the fact that your engineer friend also loaded new firmware into the Cyton mainboard RFduino, correct? (And possibly the dongle as well.) That mainboard RFduino firmware would then take data (serial bytes) received on the mainboard RFduino RF_RXD pin, and send it out to the PIC32 on the mainboard RFduino TxD pin.
And reverse the role with the bytes coming in on RxD from PIC32, going out on the mainboard RFduino RF_TXD pin.
While this may 'work', note that you are defeating entirely the isolation between the Cyton and mains power supply. Such as potential malfunctions that could connect mains overvoltages to the Cyton pins. In the case of the wired usb connection, the usb isolator prevents this. Since it contains special protection circuitry.
But still, congratulations on finding a solution that works for you. I do believe you have a malfunctioning RFduino radio component in the dongle or Cyton mainboard, that was the cause of your excessive packet errors.
Regards, William
The search link I gave previously for the wired usb does this more safely. The general idea is that you run a (lightweight thin) usb cable from the laptop to the Cyton mainboard. At the laptop side, a usb isolator (such as from Adafruit) connects the laptop usb port to the cable. Thus all signals on the usb cable are overvoltage protected.
On the Cyton mainboard, a FTDI 'breakout board' (small circuit board) containing an FTDI usb to serial converter, is mounted to the Cyton with double stick tape. Then the FTDI Tx Rx pins are cross connected to the PIC32 serial port 2 Rx Tx pins. Finally the PIC32 firmware is slightly modified to use the serial port 2 I/O instead of the default serial port 1. PIC32 serial port 1 is hardwired connected to the RFduino Rx Tx pins; and is used by the default Bluetooth link.
Regards,
Hi William,
You are right. Our engineer was wrong.
After I switched back the setting to wireless (the original bluetooth), no problem occurs.
Thanks.
Well, I applaud the creativity of you and your engineer for finding a way to do the wired connection. In the process of doing that, you loaded by-pass / pass-through code in one or both RFduinos.
So if you RELOADED the standard default firmware in both RFduinos after your wired tests, (to return to wireless) that possibly repaired a firmware glitch that might have existed. And that previous glitch could have been causing your packet loss.
Best regards, William