Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

May be dropping signals from messages with too many signals #306

Closed
peplin opened this issue Sep 29, 2014 · 3 comments
Closed

May be dropping signals from messages with too many signals #306

peplin opened this issue Sep 29, 2014 · 3 comments
Labels

Comments

@peplin
Copy link
Member

peplin commented Sep 29, 2014

Discussion: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/openxc/sX0P1IBssIs/REDLCUPL1o0J

@peplin
Copy link
Member Author

peplin commented Oct 7, 2014

The first step is to create a test that sets up 2 CAN messages with 8 signals each as in the example posted in the group, and see if it can parse all of them. If it works in a unit test, write a functional test to see if it's hardware-specific issue.

peplin added a commit that referenced this issue Oct 9, 2014
This is a first attempt at finding the root cause of #306. It's passing
without any changes, so I think the problem must be in the hardware
specific parts of the code. I will work next on creating a functional
test.
peplin added a commit that referenced this issue Oct 10, 2014
See #306 - still can't get it to fail. Is it UART?
@peplin
Copy link
Member Author

peplin commented Oct 10, 2014

I wasn't able to reproduce this issue via USB, but I did find one problem when using UART (Bluetooth) on the reference VI:

{"timestamp": 1412909913.019663, "name": "signal1", "value": 5.7}
{"timestamp": 1412909913.020916, "name": "signal2", "value": 0.1}
{"timestamp": 1412909913.021835, "name": "signal3", "value": 16.4}
{"timestamp": 1412909913.025014, "name": "signal4", "value": 0.3}
{"timestamp": 1412909913.026139, "name": "signal5", "value": 8.1}
{"timestamp": 1412909913.028094, "name": "signal6", "value": 0.3}
{"timestamp": 1412909913.028597, "name": "signal7", "value": 5}
{"timestamp": 1412909923.24624, "name": "signal10", "value": 0.3}
{"timestamp": 1412909923.252771, "name": "signal11", "value": 5.2}
{"timestamp": 1412909923.25356, "name": "signal12", "value": 0.3}
{"timestamp": 1412909923.254341, "name": "signal13", "value": 20.200001}
{"timestamp": 1412909923.255105, "name": "signal14", "value": 0.1}
{"timestamp": 1412909923.262961, "name": "signal15", "value": 22.4}
{"timestamp": 1412909923.264086, "name": "signal9", "value": 17.9}

it's dropping signal8 and signal16, the last signal in each set of 8. That's not exactly what the original bug stated, but perhaps fixing that will fix the other problem too.

@peplin
Copy link
Member Author

peplin commented Oct 10, 2014

I belive I've fixed this - there was a race condition with UART on the LPC17xx where you could lose outgoing data. I wasn't ever able to reproduce it as seriously as in the original bug report (i.e. missing a full 7 signals from a message) but I think that's because I was sending the 2 CAN messages with some delay in between. I'll re-open this ticket if it's still a problem after the next release.

@peplin peplin closed this as completed Oct 10, 2014
@peplin peplin removed the ready label Oct 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant