-
Notifications
You must be signed in to change notification settings - Fork 9
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
CAN Address Claiming #113
Comments
Thanks @aaron97neu for recalling the blockers. We should start by seeing if we have address claims in the logs. we should be able to claim our address at any time. However, autobaud detection will make it even more likely we miss address claims. |
I remember hearing that newer CAN chips have build in auto-baud-rate detection. Is that correct and something we can feasibly integrate with the avenashield? Unsure how quick it is, but a hardware chip should theoretically be able to detect the rate by the first few bits, right? |
You might be able to exploit the fact that you’ll be starting up most of the time in the same tractor, so the most likely baud speed is the one you had last time you turned on? i.e. ISOBlue deployment just involves starting the tractor twice? Just a thought.
Aaron
… On Jan 22, 2021, at 10:34 AM, Andrew Balmos ***@***.***> wrote:
Thanks @aaron97neu <https://github.com/aaron97neu> for recalling the blockers. We should start by seeing if we have address claims in the logs.
we should be able to claim our address at any time.
However, autobaud detection will make it even more likely we miss address claims.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2KEUH3EIF7K2HTYZL437TS3GLJ5ANCNFSM4WOUV3VQ>.
|
@aaron97neu Maybe. I don't see any support for that in SocketCAN, but maybe it is coming if hardware is starting to support it. |
@aultac I was thinking that as well, same if we missed the address claiming once in a while. Deploying an isoblue currently involves a few power cycles to ensure things are working fine The issue is the logs for the first/last power cycle of any deployment could be considered unreliable as it might not have realized it is on a new machiene. How terrible that is depends on how we use them and how we deploy them |
@aultac The problem is having it wrong at all breaks the machine badly. If we assume it was the same as last time, then it might break the next machine when IB is moved. At Cyrus "break" means persistent errors even after IB was disconnected and the machine was restarted. We had to flip the battery switch to get monitor back in working order and we had a calm and collected, but concerned farmer/Cyrus' father. |
@abalmos iirc the software based auto-baud rate detection is done by being in listen-only mode and cycling through known/guessed baud rates until we start receiving data I assume that if we were to use @aultac 's idea we would use the last good baud rate as the first guess but still be in listen-only mode. If we are wrong, we cause no issues and just move on to the next guess (losing data in the meantime). If we are correct, we get data quickly but still may lose some switching out of read-only mode |
@aaron97neu That's true, that may work. You might have to bring the interface up and down to change the listen-only flag--but I could be recalling that wrong? We can start by checking for address claims in our current logs. If we don't see them in Cyrus' data, then IB takes too long to start-up. That is a much harder problem to overcome. |
Agreed. Will be interesting to see. We need to make sure to differentiate between machines that remove power to the isoblue on key off and those that don't @facastiblancor If we can query for the machine identification data, it would make things easier. Any way to find this out? |
Related to #112, we will need to claim an address on the CAN bus in order to query for information. This will have to disable the listen-only mode that we currently use
Mentioned by @aultac on 1/22/21 meeting but has been a known issue for a while now
Questions/roadblocks
The text was updated successfully, but these errors were encountered: