{"action":"closed","issue":{"url":"https://api.github.com/repos/ftctechnh/ftc_app/issues/283","repository_url":"https://api.github.com/repos/ftctechnh/ftc_app","labels_url":"https://api.github.com/repos/ftctechnh/ftc_app/issues/283/labels{/name}","comments_url":"https://api.github.com/repos/ftctechnh/ftc_app/issues/283/comments","events_url":"https://api.github.com/repos/ftctechnh/ftc_app/issues/283/events","html_url":"https://github.com/ftctechnh/ftc_app/issues/283","id":193275078,"number":283,"title":"Modern Robotics Gyro sampling interval degrades rapidly when adding more I2C sensors.","user":{"login":"trc492","id":10370757,"avatar_url":"https://avatars.githubusercontent.com/u/10370757?v=3","gravatar_id":"","url":"https://api.github.com/users/trc492","html_url":"https://github.com/trc492","followers_url":"https://api.github.com/users/trc492/followers","following_url":"https://api.github.com/users/trc492/following{/other_user}","gists_url":"https://api.github.com/users/trc492/gists{/gist_id}","starred_url":"https://api.github.com/users/trc492/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/trc492/subscriptions","organizations_url":"https://api.github.com/users/trc492/orgs","repos_url":"https://api.github.com/users/trc492/repos","events_url":"https://api.github.com/users/trc492/events{/privacy}","received_events_url":"https://api.github.com/users/trc492/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-12-03T08:38:29Z","updated_at":"2016-12-03T08:49:25Z","closed_at":"2016-12-03T08:49:25Z","body":"The issue is detailed in this forum thread.\r\nhttp://ftcforum.usfirst.org/showthread.php?7529-Odd-problem-with-Core-Device-Interface-(seems-to-impact-both-Color-Sensor-and-ODS)\r\nI have written a simple opmode to test the issue and noticed that when we have 4 I2C sensors: 1 MR gyro, 2 MR color sensors and 1 MR range sensor, the gyro heading data doesn't change for approx. 300 msec. This performance is unacceptable for doing close loop control. I can't explain why the sampling interval is so bad considering the I2C bus is running at 100 kHz (approx. 100 kbps). because each sensor would have to transmit 1 kbyte for each bus transaction in order to have this kind of bad performance. So I suspect it is an I2C software architectural issue. Please look into it. Our robot can't turn accurately as a result. It often oscillates indefinitely. As a quick remedy, if you could provide an API to enable/disable an I2C device reader, that will help because most of the time, we will be using just one I2C device at a time. So we can turn off other I2C devices. For example, when the robot is turning, it is unlikely we would access the color sensor that detects the beacon \r\n\r\ncolor, or the color sensor to detect a line.\r\n[TestCode.zip](https://github.com/ftctechnh/ftc_app/files/628761/TestCode.zip)\r\n"}}
{"actor":{"display_login":"trc492"}}