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

CAN Address Claiming #113

Open
aaron97neu opened this issue Jan 22, 2021 · 9 comments
Open

CAN Address Claiming #113

aaron97neu opened this issue Jan 22, 2021 · 9 comments
Labels
discussion Discussion issue about a new feature enhancement New feature or request

Comments

@aaron97neu
Copy link
Member

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

  • Is there a time restriction to claim an address? If we startup slow, can we still claim?
  • Autobaudrate detection - how can we ensure that we are on the right baud rate?
  • We need to be absolutely sure we don't crash the bus or cause other issues
@aaron97neu aaron97neu added enhancement New feature or request discussion Discussion issue about a new feature labels Jan 22, 2021
@abalmos
Copy link
Member

abalmos commented Jan 22, 2021

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.

@aaron97neu
Copy link
Member Author

aaron97neu commented Jan 22, 2021

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?

@aultac
Copy link
Member

aultac commented Jan 22, 2021 via email

@abalmos
Copy link
Member

abalmos commented Jan 22, 2021

@aaron97neu Maybe. I don't see any support for that in SocketCAN, but maybe it is coming if hardware is starting to support it.

@aaron97neu
Copy link
Member Author

@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

@abalmos
Copy link
Member

abalmos commented Jan 22, 2021

@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.

@aaron97neu
Copy link
Member Author

aaron97neu commented Jan 22, 2021

@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

@abalmos
Copy link
Member

abalmos commented Jan 22, 2021

@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.

@aaron97neu
Copy link
Member Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion issue about a new feature enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants