Constant serial bytes available

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Constant serial bytes available
#1
Has anyone ever experienced a problem related to receiving constant serial bytes available? There seems to be a short or some sort of constant streaming of bytes such that the Bpod thinks there are tons of events and just rushes through all protocols. Has anyone ever encountered this issue? I have replicated on both the original Bpod and Gen2 with multiple different versions of the firmware leading me to believe it is hardware related. Has anyone ever encountered this issue? Any likely places I could look for a short or is this also possibly software related?


Code:
BpodSystem.SerialPort.read(BpodSystem.SerialPort.bytesAvailable, 'uint8'); pause(0.1); BpodSystem.SerialPort.bytesAvailable

>>> 556
Reply
#2
Hi Francisco

I definitely haven't seen an error like that, across hardware and software.
One thing that comes to mind, is the floating input lines serving the port input channels. A pull-down resistor on the port interface board keeps the line stable when it's connected - but if disconnected, the line is floating and can spam the system with events each time it flips between logic states

In the settings menu from the Bpod console, select the "Port" icon and you should see a window like this:

   

Make sure you don't have ports selected, that are not physically connected.

If this does not help, the next step is to identify the data that's arriving. What gets stored in 'Message' when you run this line?


Code:
Message = BpodSystem.SerialPort.read(BpodSystem.SerialPort.bytesAvailable, 'uint8')


Thanks!
Reply
#3
Thanks for the response!

I double checked the Port menu and indeed activating only ports that are connected still gives me the same issue.

If I run a protocol and it speeds through at the end I get a Message that is 12292 elements long with a pattern of 1, 5, 68, 69, 70, 71 ,72. 

Code:
>> Message(1:100)

ans =

 Columns 1 through 29

   1    5   68   69   70   71   72    1    5   68   69   70   71   72    1    5   68   69   70   71   72    1    5   68   69   70   71   72    1

 Columns 30 through 58

   5   68   69   70   71   72    1    5   68   69   70   71   72    1    5   68   69   70   71   72    1    5   68   69   70   71   72    1    5

 Columns 59 through 87

  68   69   70   71   72    1    5   68   69   70   71   72    1    5   68   69   70   71   72    1    5   68   69   70   71   72    1    5   68

 Columns 88 through 100

  69   70   71   72    1    5   68   69   70   71   72    1    5


I should mention that I also get the same problem if I run everything without any ports selected at all the protocol will still have this issue of constant new messages, with 12292 bytes waiting to be read.

Thanks, 

Francisco
Reply
#4
Hi Francisco


A bit more information will help nail this:

1. Is this happening on one Bpod state machine? Or on several?
2. Is the machine you used to generate the sequences in the last post hardware v0.7+, using the Gen2 repository? Or v0.5 + original Bpod repo?
3. Let's find out what those events are. If using the Gen2 repository, you can type:

BpodSystem.StateMachineInfo.EventNames

at the command line. This will list the name of each possible event, so we can identify the events you're seeing.

If using the master repository, the command is:

BpodSystem.EventNames

4. What is your OS, MATLAB version and do you have PsychToolbox installed?

5. Are there any boards besides the behavior ports connected to the Bpod device (via BNC cables, wire terminals or serial ports)?

Thanks!
Reply
#5
Hi Josh

1. I can replicate this issue on another Bpod 0.5

2. The machine is v0.5 using Bpod_gen2 with the latest 0.5 firmware from the Gen2 repository (I have tried different versions of the firmware but I will try going back to 0.5 + original repo)

3. Returning the event names gives..

Code:
Messages =

 Columns 1 through 9

   'Serial1_1'    'Serial1_2'    'Serial1_3'    'Serial1_4'    'Serial1_5'    'Serial1_6'    'Serial1_7'    'Serial1_8'    'Serial1_9'

 Columns 10 through 18

   'Serial1_10'    'Serial2_1'    'Serial2_2'    'Serial2_3'    'Serial2_4'    'Serial2_5'    'Serial2_6'    'Serial2_7'    'Serial2_8'

 Columns 19 through 27

   'Serial2_9'    'Serial2_10'    'SoftCode1'    'SoftCode2'    'SoftCode3'    'SoftCode4'    'SoftCode5'    'SoftCode6'    'SoftCode7'

 Columns 28 through 37

   'SoftCode8'    'SoftCode9'    'SoftCode10'    'BNC1High'    'BNC1Low'    'BNC2High'    'BNC2Low'    'Wire1High'    'Wire1Low'    'Wire2High'

 Columns 38 through 47

   'Wire2Low'    'Wire3High'    'Wire3Low'    'Wire4High'    'Wire4Low'    'Port1In'    'Port1Out'    'Port2In'    'Port2Out'    'Port3In'

 Columns 48 through 57

   'Port3Out'    'Port4In'    'Port4Out'    'Port5In'    'Port5Out'    'Port6In'    'Port6Out'    'Port7In'    'Port7Out'    'Port8In'

 Columns 58 through 63

   'Port8Out'    'GlobalTimer1_Start'    'GlobalTimer2_Start'    'GlobalTimer3_Start'    'GlobalTimer4_Start'    'GlobalTimer5_Start'

 Columns 64 through 69

   'GlobalTimer1_End'    'GlobalTimer2_End'    'GlobalTimer3_End'    'GlobalTimer4_End'    'GlobalTimer5_End'    'GlobalCounter1_End'

 Columns 70 through 76

   'GlobalCounter2_End'    'GlobalCounter3_End'    'GlobalCounter4_End'    'GlobalCounter5_End'    'Condition1'    'Condition2'    'Condition3'

 Columns 77 through 82

   'Condition4'    'Condition5'    'Serial1Jump'    'Serial2Jump'    'SoftJump'    'Tup'


4. Windows 7 // MATLAB R2015b // Yes, PTB 3 and it is being used for the backend

5. Nothing else is connected at the moment except the two behavior ports, and when connected their functionality is normal (e.g. led and valve trigger normally) when not running a state machine.
Reply
#6
Hi Francisco

My best guess at this point is mismatched firmware. 
For now, Bpod hardware  v0.5 has a quirk, where its firmware needs to be called version 5 in order for the correct bits of hardware-specific code to be included - so it's impossible to tell when firmware is mismatched to the MATLAB code. It gets worse - the Gen2 repository's firmware/Bpod r0_5/ folder had outdated firmware; the latest was in /Gen2/BpodStateMachine_r05.

I corrected this in my latest push to the repository - there is now only 1 copy of Bpod 0.5 firmware, and it lives in /firmware/Bpod0_5/

I tested this firmware with my trusty r0.5, and it works. Do you see the same thing?

Urgently, I need to fix the version system, so that for v0.5, a unique machineType includes the proper code bits, and firmwareVersion is free to vary. A lot has to change under the hood, but it's been a mess for too long. I'll try to get this done over the weekend.

-J
Reply
#7
That fixed it. Many thanks!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)