Meeting Notes for AGL Connectivity Expert Group
February 9, 2023
Attendees: Walt, Scott, Jan-Simon,
January 26, 2023
Attendees: Walt, Scott, Jan-Simon, Markus Wolf (AVL), Andrea Pferscher (TU Graz)
January 12, 2023
Attendees: Walt, Scott
CAN/ Vehicle Signaling
6/1
7/28
8/11
8/25
9/8
9/21
Uploaded fixes for kuksa_viss_client (cert issue w/ python, cmd2 utility fix) - master and needlefish
Likely update kuksa to get grpc
10/6
11/3
12/15
New:
December 15, 2022
Attendees: Walt, Jan-Simon, Scott
CAN/ Vehicle Signaling
6/1
7/28
8/11
8/25
9/8
9/21
Uploaded fixes for kuksa_viss_client (cert issue w/ python, cmd2 utility fix) - master and needlefish
Likely update kuksa to get grpc
10/6
11/3
12/15
New:
November 3, 2022
Attendees: Walt, Jan-Simon, Scott
CAN/ Vehicle Signaling
6/1
7/28
8/11
8/25
9/8
9/21
Uploaded fixes for kuksa_viss_client (cert issue w/ python, cmd2 utility fix) - master and needlefish
Likely update kuksa to get grpc
10/6
11/3
New:
October 6, 2022
Attendees: Walt, Paul, Scott
CAN/ Vehicle Signaling
6/1
7/28
8/11
8/25
9/8
9/21
Uploaded fixes for kuksa_viss_client (cert issue w/ python, cmd2 utility fix) - master and needlefish
Likely update kuksa to get grpc
10/6
New:
September 22, 2022
Attendees: Jan-Simon, Scott, Ayush Kumar,
CAN/ Vehicle Signaling
6/1
7/28
8/11
8/25
9/8
9/21
Uploaded fixes for kuksa_viss_client (cert issue w/ python, cmd2 utility fix) - master and needlefish
Likely update kuksa to get grpc
New:
September 8, 2022
Attendees: Walt, Scott, Shubkam, Shruti
New:
August 25 2022
Attendees: Walt, Scott, Jan-Simon
New:
August 11 2022
Attendees: Walt, Jan-Simon, Scott, Aakash
New:
July 28, 2022
Attendees: Walt, Jan-Simon, Scott, Bernard
New:
July 14, 2022
Attendees: Walt, Jan-Simon, Scott
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
1/27 - No update for Bluetooth. Connman wrapper is ready to be pushed which will fix the settings app.
2/10 - The Connman wrapper has been merged. There is a known issue with BLuetooth start up requiring a manual rfkilll to get running on master (SPEC-4253). Scott looking at fixing that.
New:
June 2, 2022
Attendees: Walt, Jan-Simon, Scott
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
1/27 - No update for Bluetooth. Connman wrapper is ready to be pushed which will fix the settings app.
2/10 - The Connman wrapper has been merged. There is a known issue with BLuetooth start up requiring a manual rfkilll to get running on master (SPEC-4253). Scott looking at fixing that.
New:
April 21, 2022
Attendees: Walt, Jan-Simon,
CAN/ Vehicle Signaling
2/10
3/10
Scott has the kuksa.val server building, booting up, and starting. Going to test python client which is used for their CAN messaging via WebSockets. Subscription
API is missing things like notification on a range of values or only when a change of value is detected. Noted that this is a reference implementation of the
W3C spec. gRPC implementation does not have subscription implemented at all (only set and get).
3/24
We will have the kuksa.val building and running with their VISS
API for Marlin.
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
1/27 - No update for Bluetooth. Connman wrapper is ready to be pushed which will fix the settings app.
2/10 - The Connman wrapper has been merged. There is a known issue with BLuetooth start up requiring a manual rfkilll to get running on master (SPEC-4253). Scott looking at fixing that.
New:
March 24, 2022
Attendees: Walt, Jan-Simon, Scott, Richard, Bernard
CAN/ Vehicle Signaling
2/10
3/10
Scott has the kuksa.val server building, booting up, and starting. Going to test python client which is used for their CAN messaging via WebSockets. Subscription
API is missing things like notification on a range of values or only when a change of value is detected. Noted that this is a reference implementation of the
W3C spec. gRPC implementation does not have subscription implemented at all (only set and get).
3/24
We will have the kuksa.val building and running with their VISS
API for Marlin.
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
1/27 - No update for Bluetooth. Connman wrapper is ready to be pushed which will fix the settings app.
2/10 - The Connman wrapper has been merged. There is a known issue with BLuetooth start up requiring a manual rfkilll to get running on master (SPEC-4253). Scott looking at fixing that.
New:
March 10, 2022
Attendees: Walt, Jan-Simon, Scott, Paul
CAN/ Vehicle Signaling
2/10
3/10
Scott has the kuksa.val server building, booting up, and starting. Going to test python client which is used for their CAN messaging via WebSockets. Subscription
API is missing things like notification on a range of values or only when a change of value is detected. Noted that this is a reference implementation of the
W3C spec. gRPC implementation does not have subscription implemented at all (only set and get).
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
1/27 - No update for Bluetooth. Connman wrapper is ready to be pushed which will fix the settings app.
2/10 - The Connman wrapper has been merged. There is a known issue with BLuetooth start up requiring a manual rfkilll to get running on master (SPEC-4253). Scott looking at fixing that.
New:
February 24, 2022
Attendees: Walt, Scott,
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
1/27 - No update for Bluetooth. Connman wrapper is ready to be pushed which will fix the settings app.
2/10 - The Connman wrapper has been merged. There is a known issue with BLuetooth start up requiring a manual rfkilll to get running on master (SPEC-4253). Scott looking at fixing that.
New:
February 10, 2022
Attendees: Walt, Jan-Simon, Scott, Chih-Ming, Eric, Heewon
CAN/ Vehicle Signaling
10/7
11/4
Discussed path forward with removal of App FW. Jan-Simon will try to set up a meeting with Oliver H. to discuss how VW and SocketCAN are being used.
Initial thought is to throw out the Signal Composer since it is tightly coupled to the App FW and give apps access to binary CAN messages or to subscribe to a field in CAN messages.
Create some CANOE compatible method for creating the message libraries.
Use of gRPC for IPC?
11/18
12/2
12/16
1/13
1/27
2/10
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
1/27 - No update for Bluetooth. Connman wrapper is ready to be pushed which will fix the settings app.
2/10 - The Connman wrapper has been merged. There is a known issue with BLuetooth start up requiring a manual rfkilll to get running on master (SPEC-4253). Scott looking at fixing that.
New:
Eric asked about open source interfaces to vehicle micros. Suggested that IC EG is working on adding
ICCOM to AGL.
-
January 27, 2022
Attendees: Walt, Jan-Simon, Scott, Chih-Ming, Paul, Saket
CAN/ Vehicle Signaling
10/7
11/4
Discussed path forward with removal of App FW. Jan-Simon will try to set up a meeting with Oliver H. to discuss how VW and SocketCAN are being used.
Initial thought is to throw out the Signal Composer since it is tightly coupled to the App FW and give apps access to binary CAN messages or to subscribe to a field in CAN messages.
Create some CANOE compatible method for creating the message libraries.
Use of gRPC for IPC?
11/18
12/2
12/16
1/13
1/27
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
1/27 - No update for Bluetooth. Connman wrapper is ready to be pushed which will fix the settings app.
New:
January 13, 2022
Attendees: Walt, Jan-Simon, Scott
CAN/ Vehicle Signaling
10/7
11/4
Discussed path forward with removal of App FW. Jan-Simon will try to set up a meeting with Oliver H. to discuss how VW and SocketCAN are being used.
Initial thought is to throw out the Signal Composer since it is tightly coupled to the App FW and give apps access to binary CAN messages or to subscribe to a field in CAN messages.
Create some CANOE compatible method for creating the message libraries.
Use of gRPC for IPC?
11/18
12/2
12/16
1/13
Bluetooth
11/4 - Scott looking at how get Bluetooth working with App FW removal. Plan is to remove the existing binding code
12/2 - Scott making progress on removal of App FW binding.
1/13 - Bluetooth done for Marlin, settings app still WIP for networking.
New:
December 16, 2021
Attendees: Walt, Jan-Simon, Scott, Matteo Z.(Western Digital)
CAN/ Vehicle Signaling
10/7
11/4
Discussed path forward with removal of App FW. Jan-Simon will try to set up a meeting with Oliver H. to discuss how VW and SocketCAN are being used.
Initial thought is to throw out the Signal Composer since it is tightly coupled to the App FW and give apps access to binary CAN messages or to subscribe to a field in CAN messages.
Create some CANOE compatible method for creating the message libraries.
Use of gRPC for IPC?
11/18
12/2
12/16
New:
December 2, 2021
Attendees: Walt, Jan-Simon, Scott, Damiano
CAN/ Vehicle Signaling
10/7
11/4
Discussed path forward with removal of App FW. Jan-Simon will try to set up a meeting with Oliver H. to discuss how VW and SocketCAN are being used.
Initial thought is to throw out the Signal Composer since it is tightly coupled to the App FW and give apps access to binary CAN messages or to subscribe to a field in CAN messages.
Create some CANOE compatible method for creating the message libraries.
Use of gRPC for IPC?
11/18
12/2
New:
November 18, 2021
Attendees: Walt, Jan-Simon, Scott, Paul, Chih-Ming
CAN/ Vehicle Signaling
10/7
11/4
Discussed path forward with removal of App FW. Jan-Simon will try to set up a meeting with Oliver H. to discuss how VW and SocketCAN are being used.
Initial thought is to throw out the Signal Composer since it is tightly coupled to the App FW and give apps access to binary CAN messages or to subscribe to a field in CAN messages.
Create some CANOE compatible method for creating the message libraries.
Use of gRPC for IPC?
11/18
New:
November 4, 2021
Attendees: Walt, Scott, Jan-Simon, Damiano, Raouf
CAN/ Vehicle Signaling
10/7
11/4
Discussed path forward with removal of App FW. Jan-Simon will try to set up a meeting with Oliver H. to discuss how VW and SocketCAN are being used.
Initial thought is to throw out the Signal Composer since it is tightly coupled to the App FW and give apps access to binary CAN messages or to subscribe to a field in CAN messages.
Create some CANOE compatible method for creating the message libraries.
Use of gRPC for IPC?
New:
October 7, 2021
Attendees: Walt, Scott, Chi-Ming, Sergio
New:
September 23, 2021
Attendees: Walt, Jan-Simon, Scott, Chih-Ming
Chih-Ming is using the RPI3 for their telematics demo. Discussed best way to go about it. May revisit removal of Pi3 support for Lamprey for Telematics profile only if Chih-Ming has a need.
Discussed Daniel's latest work
7/29
Update: Platform can use pi4 underneath, so no pi3 required.
Trying to integrate their application using the SDK
8/12
Chih-Ming - switched to RPI4 with
Waveshare 5g modem. Able to build RPI 64-bit image and run their software. Able to receive CAN data via CAN board.
8/26
9/9
Chih-Ming having problems with 4 of the 6 RPI 4 modules that ACAIS has do not boot due to not seeing the partitions. Might be related to
https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl/+/26624 which fixes an issue seen with newer versions of the RPI 4 hardware. Chi-Ming to check the versions of his boards. Scott and Jan-Simon will look at the best way to get this into the build (either directly from upstream or this change.)
9/23
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
6/18
7/1
Thomas last day is Monday, Starting his presentation for AGL Tech Day. He shared a few student apps from Github. Will include the final links in his Tech Day presentation.
Scott hoping to get back to CAN next week.
7/15
8.12
8/26
9/23
Scott tested CAN FD Pi hats with Debian and they work. Will need a 5.10 kernel to get it to work on RPI 4.
Tested CAN on the reference hardware. Works but the driver is throwing a lot of errors. Might be a problem with the way he has it wired.
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
7/29
8/12
9/9
Scott working with Ito-san on the CAN power enablement patch that he submitted.
Having issues with BT audio. A2DP stuttering so badly as to be unusable (same issue seen on KF). Scott suspects a PipeWire issues and will reach out to George. HFP does not work at all. Most likely needs a special PipeWire or WirePlumber change to enable this.
New:
September 9, 2021
Attendees: Walt, Jan-Simon, Scott, Chih-Ming
Chih-Ming is using the RPI3 for their telematics demo. Discussed best way to go about it. May revisit removal of Pi3 support for Lamprey for Telematics profile only if Chih-Ming has a need.
Discussed Daniel's latest work
7/29
Update: Platform can use pi4 underneath, so no pi3 required.
Trying to integrate their application using the SDK
8/12
Chih-Ming - switched to RPI4 with
Waveshare 5g modem. Able to build RPI 64-bit image and run their software. Able to receive CAN data via CAN board.
8/26
9/9
Chih-Ming having problems with 4 of the 6 RPI 4 modules that ACAIS has do not boot due to not seeing the partitions. Might be related to
https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl/+/26624 which fixes an issue seen with newer versions of the RPI 4 hardware. Chi-Ming to check the versions of his boards. Scott and Jan-Simon will look at the best way to get this into the build (either directly from upstream or this change.)
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
6/18
7/1
Thomas last day is Monday, Starting his presentation for AGL Tech Day. He shared a few student apps from Github. Will include the final links in his Tech Day presentation.
Scott hoping to get back to CAN next week.
7/15
8.12
8/26
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
7/29
8/12
9/9
Scott working with Ito-san on the CAN power enablement patch that he submitted.
Having issues with BT audio. A2DP stuttering so badly as to be unusable (same issue seen on KF). Scott suspects a PipeWire issues and will reach out to George. HFP does not work at all. Most likely needs a special PipeWire or WirePlumber change to enable this.
New:
August 26, 2021
Attendees: Walt, Jan-Simon, Scott, Richard
Chih-Ming is using the RPI3 for their telematics demo. Discussed best way to go about it. May revisit removal of Pi3 support for Lamprey for Telematics profile only if Chih-Ming has a need.
Discussed Daniel's latest work
7/29
Update: Platform can use pi4 underneath, so no pi3 required.
Trying to integrate their application using the SDK
8/12
Chih-Ming - switched to RPI4 with
Waveshare 5g modem. Able to build RPI 64-bit image and run their software. Able to receive CAN data via CAN board.
8/26
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
6/18
7/1
Thomas last day is Monday, Starting his presentation for AGL Tech Day. He shared a few student apps from Github. Will include the final links in his Tech Day presentation.
Scott hoping to get back to CAN next week.
7/15
8.12
8/26
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
7/29
8/12
New:
August 12, 2021
Attendees: Walt, Jan-Simon, Scott, Chih-Ming
Chih-Ming is using the RPI3 for their telematics demo. Discussed best way to go about it. May revisit removal of Pi3 support for Lamprey for Telematics profile only if Chih-Ming has a need.
Discussed Daniel's latest work
7/29
Update: Platform can use pi4 underneath, so no pi3 required.
Trying to integrate their application using the SDK
8/12
Chih-Ming - switched to RPI4 with
Waveshare 5g modem. Able to build RPI 64-bit image and run their software. Able to receive CAN data via CAN board.
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
6/18
7/1
Thomas last day is Monday, Starting his presentation for AGL Tech Day. He shared a few student apps from Github. Will include the final links in his Tech Day presentation.
Scott hoping to get back to CAN next week.
7/15
8.12
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
7/29
8/12
New:
July 29, 2021
Attendees: Walt, Jan-Simon, Chih-Ming, Bernard
Chih-Ming is using the RPI3 for their telematics demo. Discussed best way to go about it. May revisit removal of Pi3 support for Lamprey for Telematics profile only if Chih-Ming has a need.
Discussed Daniel's latest work
7/29
Update: Platform can use pi4 underneath, so no pi3 required.
Trying to integrate their application using the SDK
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
6/18
7/1
Thomas last day is Monday, Starting his presentation for AGL Tech Day. He shared a few student apps from Github. Will include the final links in his Tech Day presentation.
Scott hoping to get back to CAN next week.
7/15
7/29
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
7/29
New:
Scott looked at telephony and call hold support. More digging into ofono required.
KF Bluetooth (and lateron the refhw module) need some debugging of a race between the binding and the userspace daemon startup
July 15, 2021
Attendees: Jan-Simon, Scott, Eric,
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
6/18
7/1
Thomas last day is Monday, Starting his presentation for AGL Tech Day. He shared a few student apps from Github. Will include the final links in his Tech Day presentation.
Scott hoping to get back to CAN next week.
7/15
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
Chih-Ming is using the RPI3 for their telematics demo. Discussed best way to go about it. May revisit removal of Pi3 support for Lamprey for Telematics profile only if Chih-Ming has a need.
Discussed Daniel's latest work
New:
Scott looked at telephony and call hold support. More digging into ofono required.
KF Bluetooth (and lateron the refhw module) need some debugging of a race between the binding and the userspace daemon startup
July 1, 2021
Attendees: Walt, Jan-Simon, Thomas, Scott, Chih-Ming, Daniel CB
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
6/18
7/1
Thomas last day is Monday, Starting his presentation for AGL Tech Day. He shared a few student apps from Github. Will include the final links in his Tech Day presentation.
Scott hoping to get back to CAN next week.
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
New:
Chih-Ming is using the RPI3 for their telematics demo. Discussed best way to go about it. May revisit removal of Pi3 support for Lamprey for Telematics profile only if Chih-Ming has a need.
Discussed Daniel's latest work
June 18, 2021
Attendees: Walt, Jan-Simon, Thomas, Scott, Chih-Ming
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
6/18
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
New:
June 4, 2021
Attendees: Walt, Jan-Simon, Thomas, Scott, Bernard, Eric S (Panasonic)
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
6/4
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
New:
May 20, 2021
Attendees: Jan-Simon, Thomas, Richard, Scott, Daniel, Bala
Vehicle Signaling
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
5/20
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
5/20
New:
April 29, 2021
Attendees: Walt, Jan-Simon, Scott, Richard
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
New:
April 15, 2021
Attendees: Walt, Scott, Thomas,
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
4/15
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
New:
April 1, 2021
Attendees: Walt, Jan-Simon, Scott, Thomas, Richard, Kurokawa
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019. (SPEC-3810)
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
4/1
SPEC-3810 - CAN decoding. Scott can reproduce the issue. Has not had a lot of time to debug.
Discussed options for improving the CAN binding and signal composer. Would like to get some feedback about using Canoe format and whether pursuing Kayak as a tool for formatting messages would be something OEMs are interested in.
Most likely would get rid of Signal Composer depending on the App FW rework proposal from Collabora.
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
4/1
New:
March 4, 2021
Attendees: Walt, Jan-Simon, Scott, Thomas, Richard E
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019.
Scott received CAN-FD Pi hats so he can test that out in the near future.
3/4
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
3/4
New:
February 18, 2021
Attendees: Walt, Jan-Simon, Scott, Thomas, Richard E
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
2/18
Thomas did some more testing of Cannelloni usage. Values up to 255 are received and sent ok. Larger values are not received incorrectly. Scott suggests it is in the message JSON or maybe has todo with the CAN binding changes that IoT.bzh did in 2019.
Scott received CAN-FD Pi hats so he can test that out in the near future.
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
2/18
New:
February 4, 2021
Attendees: Walt, Jan-Simon, Scott, Tanikawa, Thomas, Richard E
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
2/4
Ref HW
1/7
2/4
Scott wired up the RF HW for CAN. Hardware is set up as CAN FD, but he does not have CAN FD capable hardware to test it. Ordered a RPI hat that is supposed to support CAN FD. He theorizes that the reference hardware can be configured for non-FD, but needs to poke around the device tree/ driver to see if it can be reconfigured.
New:
January 21, 2021
Attendees: Walt, Jan-Simon, Scott, Tanikawa
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
1/21
New:
January 7, 2021
Attendees: Walt, Jan-Simon, Scott, Thomas, Sekine, Tanikawa, Li
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
1/7 - No updates from Thomas.
CAN test failures. SPEC-3756, SPEC-3755 Scott noticed that we lost the configuration file that was in /etc as part of one of the merges last year. This is needed for the green machine demo, but would not be noticed by most users.
New:
December 10, 2020
Attendees: Jan-Simon, Scott, Thomas, Dennis
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
12/10 - Cannelloni added and it is working.
Ref HW
10/15
Booting
wifi not showing up in lspci, firmware ?, devicetree ?
need more info from Panasonic/Mazda
working: hdmi, usb2,
not working: audio (device there, likely wireplumber)
11/26
New:
November 26, 2020
Attendees: Jan-Simon, Scott, Thomas,
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni 11/26 - Cannelloni working. Thomas showed remote operation. Will send patches when ready.
Ref HW
10/15
Booting
wifi not showing up in lspci, firmware ?, devicetree ?
need more info from Panasonic/Mazda
working: hdmi, usb2,
not working: audio (device there, likely wireplumber)
11/26
New:
November 12, 2020
Attendees: Walt, Jan-Simon, Thomas, Scott, Kurokawa, Tanikawa
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
11/12 - Looked at options for remote CAN support via
Cannelloni
Ref HW
10/15
Booting
wifi not showing up in lspci, firmware ?, devicetree ?
need more info from Panasonic/Mazda
working: hdmi, usb2,
not working: audio (device there, likely wireplumber)
New:
Oct 29, 2020
Canceled due to Yocto Project Summit
Oct 15, 2020
Attendees: Walt, Jan-Simon, Michael, Thomas, Nomoto-san, Scott, Tanikawa-san
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
Ref HW
10/15
Booting
wifi not showing up in lspci, firmware ?, devicetree ?
need more info from Panasonic/Mazda
working: hdmi, usb2,
not working: audio (device there, likely wireplumber)
New:
Oct 1, 2020
Attendees: Walt, Jan-Simon, Scott, Thomas, Nimoto, Kimura
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
10/1 - Thomas back from holidays and crunch-time and is starting to look at the new version of the low-can generator.
New:
Sept 17, 2020
Attendees: Jan-Simon, Scott, Michael, Furuta, Nomoto, Kimura, Kusakabe
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
5/12 - Nomoto-san presented two documents. One with a
plan for Bluetooth development and
one document with sequence diagrams with a discussion of the Denso Ten
API. A lot of feedback was provided on the need for having the Denso
API added with an additional middleware layer that does not seem to add any benefit to the AGL implementation. Toyota and Denso Ten will discuss internally before the next meeting. Kusakabe-san verified that there is no code that will be shared by Denso Ten as part of the implementation.
6/11 - Toyota presented a revised version of their plan. The concern with the Toyota proposal is that it will introduce extra complexity without any real benefit towards meeting their use cases. Also, there is no code included from Denso-Ten so everything except the
API would be implemented from scratch. It was agreed to review the Konsulko proposal from earlier this year regarding improvements to the BT binding and implementation as well as their analysis of the Toyota use cases. Hanaoka-san's concern is that we meet the roadmap approved by the AB and SC.
6/25 - Reviewed the presentation from Walt to summarize the current status of the EG. Kimura-san would like to review the proposal from Konsulko and propose a reduced
API set. Kimura-san clarified that the implementation of the
API uses a proprietary third-party Bluetooth stack and cannot be open sourced due to contract restrictions.
7/9 - Toyota and Denso-Ten agreed to the proposal that we have Konsulko work through the priority list and propose an abstraction layer to allow BlueZ to be easily replaced by a proprietary stack. Konsulko will propose an initial plan in two weeks at the next Connectivity EG including identifying any upstream BlueZ or ofono work that may impact the schedule.
8/6 - Discussed the impact of the new Product Readiness effort on the Bluetooth and Tuner updates since the App Framework will most likely be replaced and the Bluetooth and Tuner work greatly depends on the binder implementation. Toyota and Denso Ten will come back with some new ideas on how to proceed within the Connectivity EG in the next month or so.
8/20 - Decided with the Steering Committee to push out the Bluetooth and Radio
API work until some decisions are made regarding the future direction of the App FW in the Production Readiness profile.
9/17 - No update.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
5/14 - Thomas hopes to have the converter for the CAN messages in the next two weeks.
7/9 - Thomas is back working on the project.
-
8/6 - Scott asked about plan to use CAN in the Trial version of Production Readiness plan. Nomoto-san confirmed that it includes continuing to use the existing AGL can-low-level service.
8/20 - Scott uploaded some fixes to the low-can-service to fix auto detect issues with J1939.
9/17 - Jira ticket open for the low-can binding generator not in sync with binding (SPEC-3551)
New:
August 20, 2020
Attendees: Walt, Jan-Simon, Scott, Li, Furuta, Tanikawa, Kurokawa, Nomoto, Kimura, Venkata RPT
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
5/12 - Nomoto-san presented two documents. One with a
plan for Bluetooth development and
one document with sequence diagrams with a discussion of the Denso Ten
API. A lot of feedback was provided on the need for having the Denso
API added with an additional middleware layer that does not seem to add any benefit to the AGL implementation. Toyota and Denso Ten will discuss internally before the next meeting. Kusakabe-san verified that there is no code that will be shared by Denso Ten as part of the implementation.
6/11 - Toyota presented a revised version of their plan. The concern with the Toyota proposal is that it will introduce extra complexity without any real benefit towards meeting their use cases. Also, there is no code included from Denso-Ten so everything except the
API would be implemented from scratch. It was agreed to review the Konsulko proposal from earlier this year regarding improvements to the BT binding and implementation as well as their analysis of the Toyota use cases. Hanaoka-san's concern is that we meet the roadmap approved by the AB and SC.
6/25 - Reviewed the presentation from Walt to summarize the current status of the EG. Kimura-san would like to review the proposal from Konsulko and propose a reduced
API set. Kimura-san clarified that the implementation of the
API uses a proprietary third-party Bluetooth stack and cannot be open sourced due to contract restrictions.
7/9 - Toyota and Denso-Ten agreed to the proposal that we have Konsulko work through the priority list and propose an abstraction layer to allow BlueZ to be easily replaced by a proprietary stack. Konsulko will propose an initial plan in two weeks at the next Connectivity EG including identifying any upstream BlueZ or ofono work that may impact the schedule.
8/6 - Discussed the impact of the new Product Readiness effort on the Bluetooth and Tuner updates since the App Framework will most likely be replaced and the Bluetooth and Tuner work greatly depends on the binder implementation. Toyota and Denso Ten will come back with some new ideas on how to proceed within the Connectivity EG in the next month or so.
8/20 - Decided with the Steering Committee to push out the Bluetooth and Radio
API work until some decisions are made regarding the future direction of the App FW in the Production Readiness profile.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
5/14 - Thomas hopes to have the converter for the CAN messages in the next two weeks.
7/9 - Thomas is back working on the project.
-
8/6 - Scott asked about plan to use CAN in the Trial version of Production Readiness plan. Nomoto-san confirmed that it includes continuing to use the existing AGL can-low-level service.
8/20 - Scott uploaded some fixes to the low-can-service to fix auto detect issues with J1939.
New:
August 6, 2020
Attendees: Walt, Scott, Li, Thomas, Kurokawa, Furuta, Kimura, Nomoto, Monden, Michael
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
5/12 - Nomoto-san presented two documents. One with a
plan for Bluetooth development and
one document with sequence diagrams with a discussion of the Denso Ten
API. A lot of feedback was provided on the need for having the Denso
API added with an additional middleware layer that does not seem to add any benefit to the AGL implementation. Toyota and Denso Ten will discuss internally before the next meeting. Kusakabe-san verified that there is no code that will be shared by Denso Ten as part of the implementation.
6/11 - Toyota presented a revised version of their plan. The concern with the Toyota proposal is that it will introduce extra complexity without any real benefit towards meeting their use cases. Also, there is no code included from Denso-Ten so everything except the
API would be implemented from scratch. It was agreed to review the Konsulko proposal from earlier this year regarding improvements to the BT binding and implementation as well as their analysis of the Toyota use cases. Hanaoka-san's concern is that we meet the roadmap approved by the AB and SC.
6/25 - Reviewed the presentation from Walt to summarize the current status of the EG. Kimura-san would like to review the proposal from Konsulko and propose a reduced
API set. Kimura-san clarified that the implementation of the
API uses a proprietary third-party Bluetooth stack and cannot be open sourced due to contract restrictions.
7/9 - Toyota and Denso-Ten agreed to the proposal that we have Konsulko work through the priority list and propose an abstraction layer to allow BlueZ to be easily replaced by a proprietary stack. Konsulko will propose an initial plan in two weeks at the next Connectivity EG including identifying any upstream BlueZ or ofono work that may impact the schedule.
8/6 - Discussed the impact of the new Product Readiness effort on the Bluetooth and Tuner updates since the App Framework will most likely be replaced and the Bluetooth and Tuner work greatly depends on the binder implementation. Toyota and Denso Ten will come back with some new ideas on how to proceed within the Connectivity EG in the next month or so.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
5/14 - Thomas hopes to have the converter for the CAN messages in the next two weeks.
7/9 - Thomas is back working on the project.
-
8/6 - Scott asked about plan to use CAN in the Trial version of Production Readiness plan. Nomoto-san confirmed that it includes continuing to use the existing AGL can-low-level service.
New:
July 23, 2020
Attendees: Walt, Jan-Simon, Scott, Thomas, Li
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
5/12 - Nomoto-san presented two documents. One with a
plan for Bluetooth development and
one document with sequence diagrams with a discussion of the Denso Ten
API. A lot of feedback was provided on the need for having the Denso
API added with an additional middleware layer that does not seem to add any benefit to the AGL implementation. Toyota and Denso Ten will discuss internally before the next meeting. Kusakabe-san verified that there is no code that will be shared by Denso Ten as part of the implementation.
6/11 - Toyota presented a revised version of their plan. The concern with the Toyota proposal is that it will introduce extra complexity without any real benefit towards meeting their use cases. Also, there is no code included from Denso-Ten so everything except the
API would be implemented from scratch. It was agreed to review the Konsulko proposal from earlier this year regarding improvements to the BT binding and implementation as well as their analysis of the Toyota use cases. Hanaoka-san's concern is that we meet the roadmap approved by the AB and SC.
6/25 - Reviewed the presentation from Walt to summarize the current status of the EG. Kimura-san would like to review the proposal from Konsulko and propose a reduced
API set. Kimura-san clarified that the implementation of the
API uses a proprietary third-party Bluetooth stack and cannot be open sourced due to contract restrictions.
7/9 - Toyota and Denso-Ten agreed to the proposal that we have Konsulko work through the priority list and propose an abstraction layer to allow BlueZ to be easily replaced by a proprietary stack. Konsulko will propose an initial plan in two weeks at the next Connectivity EG including identifying any upstream BlueZ or ofono work that may impact the schedule.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
5/14 - Thomas hopes to have the converter for the CAN messages in the next two weeks.
7/9 - Thomas is back working on the project.
-
New:
July 9, 2020
Attendees: Walt, Jan-Simon, Scott, Kimura, Nomoto, Monden, Thomas, Tanikawa, Magnus Damm (Renesas), Michael, Kurokawa, Kusakabel, Li
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
5/12 - Nomoto-san presented two documents. One with a
plan for Bluetooth development and
one document with sequence diagrams with a discussion of the Denso Ten
API. A lot of feedback was provided on the need for having the Denso
API added with an additional middleware layer that does not seem to add any benefit to the AGL implementation. Toyota and Denso Ten will discuss internally before the next meeting. Kusakabe-san verified that there is no code that will be shared by Denso Ten as part of the implementation.
6/11 - Toyota presented a revised version of their plan. The concern with the Toyota proposal is that it will introduce extra complexity without any real benefit towards meeting their use cases. Also, there is no code included from Denso-Ten so everything except the
API would be implemented from scratch. It was agreed to review the Konsulko proposal from earlier this year regarding improvements to the BT binding and implementation as well as their analysis of the Toyota use cases. Hanaoka-san's concern is that we meet the roadmap approved by the AB and SC.
6/25 - Reviewed the presentation from Walt to summarize the current status of the EG. Kimura-san would like to review the proposal from Konsulko and propose a reduced
API set. Kimura-san clarified that the implementation of the
API uses a proprietary third-party Bluetooth stack and cannot be open sourced due to contract restrictions.
7/9 - Toyota and Denso-Ten agreed to the proposal that we have Konsulko work through the priority list and propose an abstraction layer to allow BlueZ to be easily replaced by a proprietary stack. Konsulko will propose an initial plan in two weeks at the next Connectivity EG including identifying any upstream BlueZ or ofono work that may impact the schedule.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
5/14 - Thomas hopes to have the converter for the CAN messages in the next two weeks.
7/9 - Thomas is back working on the project.
New:
June 25, 2020
Attendees: Walt, Jan-Simon, Scott, Kimura (Denso-Ten), Nomoto, Monden (ADIT), Hanaoka, Thomas, Tanikawa, Magnus Damm (Renesas), Michael, Kurokawa
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
5/12 - Nomoto-san presented two documents. One with a
plan for Bluetooth development and
one document with sequence diagrams with a discussion of the Denso Ten
API. A lot of feedback was provided on the need for having the Denso
API added with an additional middleware layer that does not seem to add any benefit to the AGL implementation. Toyota and Denso Ten will discuss internally before the next meeting. Kusakabe-san verified that there is no code that will be shared by Denso Ten as part of the implementation.
6/11 - Toyota presented a revised version of their plan. The concern with the Toyota proposal is that it will introduce extra complexity without any real benefit towards meeting their use cases. Also, there is no code included from Denso-Ten so everything except the
API would be implemented from scratch. It was agreed to review the Konsulko proposal from earlier this year regarding improvements to the BT binding and implementation as well as their analysis of the Toyota use cases. Hanaoka-san's concern is that we meet the roadmap approved by the AB and SC.
6/25 - Reviewed the presentation from Walt to summarize the current status of the EG. Kimura-san would like to review the proposal from Konsulko and propose a reduced
API set. Kimura-san clarified that the implementation of the
API uses a proprietary third-party Bluetooth stack and cannot be open sourced due to contract restrictions.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
5/14 - Thomas hopes to have the converter for the CAN messages in the next two weeks.
New:
June 11, 2020
Attendees: Walt, Scott, Kimura (Denso-Ten), Nomoto, Moden (ADIT), Hanaoka, Li, Tanikawa,
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
5/12 - Nomoto-san presented two documents. One with a
plan for Bluetooth development and
one document with sequence diagrams with a discussion of the Denso Ten
API. A lot of feedback was provided on the need for having the Denso
API added with an additional middleware layer that does not seem to add any benefit to the AGL implementation. Toyota and Denso Ten will discuss internally before the next meeting. Kusakabe-san verified that there is no code that will be shared by Denso Ten as part of the implementation.
6/11 - Toyota presented a revised version of their plan. The concern with the Toyota proposal is that it will introduce extra complexity without any real benefit towards meeting their use cases. Also, there is no code included from Denso-Ten so everything except the
API would be implemented from scratch. It was agreed to review the Konsulko proposal from earlier this year regarding improvements to the BT binding and implementation as well as their analysis of the Toyota use cases. Hanaoka-san's concern is that we meet the roadmap approved by the AB and SC.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
5/14 - Thomas hopes to have the converter for the CAN messages in the next two weeks.
New:
May 28, 2020
May 14, 2020
Attendees: Walt, Jan-Simon, Scott, Ohiwa, Thomas, Nomoto, Kusakabe
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
5/12 - Nomoto-san presented two documents. One with a
plan for Bluetooth development and
one document with sequence diagrams with a discussion of the Denso Ten
API. A lot of feedback was provided on the need for having the Denso
API added with an additional middleware layer that does not seem to add any benefit to the AGL implementation. Toyota and Denso Ten will discuss internally before the next meeting. Kusakabe-san verified that there is no code that will be shared by Denso Ten as part of the implementation.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
5/14 - Thomas hopes to have the converter for the CAN messages in the next two weeks.
New:
April 30, 2020
Attendees: Walt, Jan-Simon, Scott, Ohiwa, Thomas, Nomoto, Swapnil
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
4/30 - Review a little of the platform vs. app breakdown provided by Scott. Toyota will review off-line for the next meeting, Nomoto-san is working on sequence charts based on their work for the next meeting, Scott is concerned that trying to put the Denso-Ten
API into AGL does not fit the application framework model and switching over to the Denso-Ten
API would be a radical change for the AGL architecture. So we would like a statement of what the goal of using the Denso-Ten
API is. Ideally we would have a short presentation from Toyota and Denso-Ten on what the goals of the effort are and whether they intend to use the AGL App FW and turn in another direction.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
4/30 - No updates
New:
April 16, 2020
Attendees: Walt, Jan-Simon, Scott, Ohiwa, Thomas, Nomoto, Parth
Toyota Bluetooth Presentation by Nomoto-san.
SPEC-3283 created as an epic to track all of the use cases. Nomoto-san or Ohiwa-san will add new Jira tickets for each use case and link them to the epic. We can start to review off-line and review in the next connectivity meeting.
Link to presentation
Reviewed the registration use cases
4/2 - Nomoto-san presented updated use cases and got feedback.
4/16 - Nomoto-san reviewed the remaining use cases in the spreadsheet which was uploaded to SPEC-3283. Scott and Matt will add columns to the spreadsheet to respond with what should already be supported in the platform (and needs a UI update) vs what is new platform work.
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
4/16 - Nothing to report from Scott, Thomas is working on a conversion tool from Canoe DBC to AGL JSON and has had some success with the first message.
New:
April 2, 2020
Attendees: Walt, Jan-Simon, Scott, Thomas, Nomoto, Kusakabe, Ohiwa, Michael, Tanikawa
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
4/2 - Scott received from new hardware, but has been busy with dunfell upgrade.
New:
March 19, 2020
Attendees: Walt, Jan-Simon, Scott, Thomas, Nomoto, Abe, Kusakabe, Matt, Ohiwa, Ron Persky, Kurokawa,
01/23
2/6 - No update
3/5 - Romain not on the call. Would like the CANOE DBC to JSON tool upstreamed or more fully developed for AGL (SPEC-3257)
3/19 - Scott investigating CAN lock ups that are seen in the green machine demo unit.
We will look for a way to have Kusakabe-san present the Tuner
API proposal he was going to make at the AMM using another format (Zoom?) in the near future.
New:
March 5, 2020
Attendees: Walt, Jan-Simon, Scott, Li, Kusakabe, Marat, Andrey, Leonid, Mikhail, Thomas
New:
We will look for a way to have Kusakabe-san present the Tuner
API proposal he was going to make at the AMM using another format (Zoom?) in the near future.
February 20, 2020
Attendees: Walt, Jan-Simon, Scott, Sekine, Tanikawa, Michael, Romain, Li, Fujiwara, Kusakabe, Kurokawa
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
8/22 - No update
9/5 - No update
11/28 - No feedback
01/23 - No feedback
02/06 - No feedback
New:
February 6, 2020
Attendees: Walt, Jan-Simon, Thomas, Scott, Kusakabe, Michael
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
8/22 - No update
9/5 - No update
11/28 - No feedback
01/23 - No feedback
02/06 - No feedback
New:
Thomas showed us some of the work his students having doing with setting up a driving simulator to use AGL. Got some feedback on their usage of CAN and Bluetooth.
Michael asked about the latest status of the LIN driver. Since the driver is working well they will close any open issues in Jira.
January 23, 2020
Attendees: Jan-Simon, Michael, Sharath, Li, George
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
8/22 - No update
9/5 - No update
11/28 - No feedback
01/23 - No feedback
New:
October 17, 2019
Attendees: Walt, Jan-Simon, Scott, Romain, Kusakabe
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
8/22 - No update
9/5 - No update
11/28 - No feedback
New Business:
October 17, 2019
Attendees: Walt, Jan-Simon, Scott, Romain, Michael, Kusakabe, Ashvinid
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
8/22 - No update
9/5 - No update
New Business:
October 3, 2019
Attendees: Walt, Jan-Simon, Scott, Romain, George, Kusakabe
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
8/22 - No update
9/5 - No update
New Business:
September 6, 2019
Attendees: Walt, Jan-Simon, Scott, Romain
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
8/22 - No update
9/5 - No update
New Business:
August 22, 2019
Attendees: Jan-Simon, Romain, Michael
* Review 2019 Roadmap for Connectivity EG
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
8/22 - No update
New Business:
July 25, 2019
Attendees: Walt, Jan-Simon, Romain, Scott, Kusakabe
* Review 2019 Roadmap for Connectivity EG
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
New Business:
July 11, 2019
Attendees: Walt, Jan-Simon, Scott, Romain, Kusakabe, Michael,
* Review 2018 Roadmap for Connectivity EG
Vehicle Signaling
4/4
4/18
5/16
J1939 work is in a sandbox, but not pushed to master yet. Requires kernel version 4.19 so testing has been taking place using QEMU. Need to check the kernel version that will be available with Renesas BSP version 3.19. Will need to make J1939 an optional feature prior to merging the sandbox due to the kernel issue.
-
6/27 - J1939 ready to be merged. Will be done for RC2. Bug fixes, improvements, and documentation are continuing for the next RC.
7/11 - J1939 merged. Writing to CAN bus will be ready shortly. Icefish planning needs to be done. Will have an idea for next meeting. Candidates include SPEC-1381 and SPEC-2498.
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
New Business:
June 27, 2019
Attendees: Walt, Jan-Simon, Scott, Romain, Kusakabe, George, Kurokawa
* Review 2018 Roadmap for Connectivity EG
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
New Business:
June 13, 2019
Attendees: Walt, Scott, Kusakabe, George, Michael, Kurokawa
* Review 2018 Roadmap for Connectivity EG
Vehicle Signaling
4/4
4/18
5/16
J1939 work is in a sandbox, but not pushed to master yet. Requires kernel version 4.19 so testing has been taking place using QEMU. Need to check the kernel version that will be available with Renesas BSP version 3.19. Will need to make J1939 an optional feature prior to merging the sandbox due to the kernel issue.
-
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
New Business:
May 30, 2019
May 16, 2019
Attendees: Walt, Romain, Scott, Michael, Chris, Jana
* Review 2018 Roadmap for Connectivity EG
Vehicle Signaling
4/4
4/18
5/16
J1939 work is in a sandbox, but not pushed to master yet. Requires kernel version 4.19 so testing has been taking place using QEMU. Need to check the kernel version that will be available with Renesas BSP version 3.19. Will need to make J1939 an optional feature prior to merging the sandbox due to the kernel issue.
-
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
New Business:
May 2, 2019
Meeting canceled due to holidays
April 18, 2019
Attendees: Walt, Jan-Simon, Romain, Scott, Shrikanth
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
New Business:
April 4, 2019
Attendees: Walt, Jan-Simon, Eric, Jana Thodeti (Panasonic), Julian (Collabora), George, Michael, Chris, Shrikanth (Panasonic), Romain, Sebastien,
Vehicle Signaling
1/24
2/7
Walt spoke to Paul Thieme of Purdue University who is working on agriculture projects and they are interested promoting AGL for ISO 11783 based on J1939 and displaying data to farm tractor operators.
J1939 implementation is currently in development. Relies on multi-frame support for CAN. Investigating whether this can be completed for HH.
Discussed how to send CAN data using the Signal Composer and Low Level CAN binding. Walt will create a JIRA ticket to document the use cases.
Kusakabe talked about how Denso-Ten will make additional use of the Signal Composer and Low Level CAN binding this year in their work on AGL.
2/21
3/21
4/4
NFC - Use of NFC for user identification.
1/24 - Reading the cards is ok. Still some issues with writing the tags with neard. Close to finishing this off once Scott get her the latest Identity agent changes.
2/7 - Raquel has the latest identity agent changes from Scott and fixing open issues.
2/21 - Identity agent changes tested and submitted to gerrit.
3/21 - NFC complete complete for now. Raquel documented some potential changes we can do in the event we get further requirements for changes in the future. Need to document how to create cards.
4/4 - Nothing to report.
Telematics requirements
Is there a use case for simultaneous connection of a hardwired phone and a Bluetooth phone? Need to check with OEMs on their system architecture. If so presents and architecture complication that needs to be thought through.
Jana clarified the potential requirements for a silver box that there is the possibility for multiple network connections in a telematics device. Could be hardwired modem + Bluetooth telephony from a personal device + Wifi at the same time.
Also possible for IVI system to have multiple Bluetooth phones connected to a silver box or IVI system and have to support multiple phone books (for one or separate users).
Encryption of personal user data.
Panasonic will think about reference hardware that can use for Telematics reference hardware.
New Business:
March 21, 2019
Attendees: Walt, Jan-Simon, Scott, George, Clement, Sebastien
Roadmap for 2019
Vehicle Signaling
1/24
2/7
Walt spoke to Paul Thieme of Purdue University who is working on agriculture projects and they are interested promoting AGL for ISO 11783 based on J1939 and displaying data to farm tractor operators.
J1939 implementation is currently in development. Relies on multi-frame support for CAN. Investigating whether this can be completed for HH.
Discussed how to send CAN data using the Signal Composer and Low Level CAN binding. Walt will create a JIRA ticket to document the use cases.
Kusakabe talked about how Denso-Ten will make additional use of the Signal Composer and Low Level CAN binding this year in their work on AGL.
2/21
3/21
NFC - Use of NFC for user identification.
1/24 - Reading the cards is ok. Still some issues with writing the tags with neard. Close to finishing this off once Scott get her the latest Identity agent changes.
2/7 - Raquel has the latest identity agent changes from Scott and fixing open issues.
2/21 - Identity agent changes tested and submitted to gerrit.
3/21 - NFC complete complete for now. Raquel documented some potential changes we can do in the event we get further requirements for changes in the future. Need to document how to create cards.
New Business:
March 7, 2019
Meeting canceled due to AMM
February 21, 2019
Attendees: Walt, Jan-Simon, Sebastien, Scott, Romain, Kusakabe, Michael
Roadmap for 2019
Vehicle Signaling
1/24
2/7
Walt spoke to Paul Thieme of Purdue University who is working on agriculture projects and they are interested promoting AGL for ISO 11783 based on J1939 and displaying data to farm tractor operators.
J1939 implementation is currently in development. Relies on multi-frame support for CAN. Investigating whether this can be completed for HH.
Discussed how to send CAN data using the Signal Composer and Low Level CAN binding. Walt will create a JIRA ticket to document the use cases.
Kusakabe talked about how Denso-Ten will make additional use of the Signal Composer and Low Level CAN binding this year in their work on AGL.
2/21
NFC - Use of NFC for user identification.
1/24 - Reading the cards is ok. Still some issues with writing the tags with neard. Close to finishing this off once Scott get her the latest Identity agent changes.
2/7 - Raquel has the latest identity agent changes from Scott and fixing open issues.
2/21 - Identity agent changes tested and submitted to gerrit.
New Business:
February 7, 2019
Attendees: Walt, Jan-Simon, Sebastien, Scott, Romain, Kusakabe
Roadmap for 2019
NFC - Use of NFC for user identification.
1/24 - Reading the cards is ok. Still some issues with writing the tags with neard. Close to finishing this off once Scott get her the latest Identity agent changes.
2/7 - Raquel has the latest identity agent changes from Scott and fixing open issues.
New Business:
January 13 and 24, 2019
Attendees: Walt, Jan-Simon, Sebastien, Michael, Romain, Chris, Scott
Roadmap for 2019
New Business:
December 13, 2018
Attendees: Walt, Jan-Simon, Sebastien, Michael, Romain
HVAC actuator in green machine #1 (from Japan) is not working correctly. Discussed debug possibilities. Michael confirmed that both demo units have updated hardware and firmware. Will create a video and share with Michael.
No Bluetooth audio on flounder or master. Need help from Thierry. Sent him an email asking for support at 6 pm.
New Business:
November 29, 2018
Attendees: Walt, Jan-Simon, Scott, Matt R, Sebastien, Romain
New Business:
November 15, 2018
Attendees: Walt, Jan-Simon, Scott, Kusakabe, Romain, Michael, Chris
New Business:
November 1, 2018
Attendees: Jan-Simon, Tom
New Business:
October 18, 2018
Canceled due to Dresden AMM
October 4, 2018
Attendees: Walt, Jan-Simon, Romain, Scott, Stephane, Michael
New Business:
September 20, 2018
Attendees: Walt, Jan-Simon, Scott
New Business:
September 6, 2018
Attendees: Walt, Matt, Sebastien, Romain
New Business:
September 6, 2018
Attendees: Walt, Matt, Sebastien, Romain
New Business:
August 23, 2018
Attendees: Walt, Jan-Simon, Romain, Matt, Sebastien
New Business:
August 9, 2018
Attendees: Walt, Michael, Chris, Romain
Discussed test methodology and packaging for CIAT tests. Schedule a separate a call to discuss with IoT.bzh and Konsulko. Tentatively May 15 after the dev call. Scott, Matt, Matt, Sebastien, Jose, Jonathan should be invited.
New Business:
July 26, 2018
Attendees: Jan-Simon, Romain, Christian, Michael,
Discussed test methodology and packaging for CIAT tests. Schedule a separate a call to discuss with IoT.bzh and Konsulko. Tentatively May 15 after the dev call. Scott, Matt, Matt, Sebastien, Jose, Jonathan should be invited.
New Business:
July 12, 2018
Attendees: Walt, Jan-Simon, Sebastien, Matt, Romain
Discussed test methodology and packaging for CIAT tests. Schedule a separate a call to discuss with IoT.bzh and Konsulko. Tentatively May 15 after the dev call. Scott, Matt, Matt, Sebastien, Jose, Jonathan should be invited.
New Business:
June 28, 2018
Attendees: Walt, Romain, Matt P, Kusakabe, Sebastien, Stephane
User profiles to allow authorized users to configure Wifi and BT
Support for additional wifi dongles and modes. Currently station mode only. Post-FF.
For 2018 - evaluate usage of connman versus network manager/modem manager for long-term especially for 4G and complex use cases.
Discussed test methodology and packaging for CIAT tests. Schedule a separate a call to discuss with IoT.bzh and Konsulko. Tentatively May 15 after the dev call. Scott, Matt, Matt, Sebastien, Jose, Jonathan should be invited.
New Business:
June 14, 2018
Attendees: Walt, Jan-Simon, Matt Porter, Sebastien, Romain, Ronan
User profiles to allow authorized users to configure Wifi and BT
Support for additional wifi dongles and modes. Currently station mode only. Post-FF.
For 2018 - evaluate usage of connman versus network manager/modem manager for long-term especially for 4G and complex use cases.
Discussed test methodology and packaging for CIAT tests. Schedule a separate a call to discuss with IoT.bzh and Konsulko. Tentatively May 15 after the dev call. Scott, Matt, Matt, Sebastien, Jose, Jonathan should be invited.
New Business:
May 31, 2018
Attendees: Jan-Simon, Jonathan Aillet, Matt Porter, Kusakabe-san,
User profiles to allow authorized users to configure Wifi and BT
Support for additional wifi dongles and modes. Currently station mode only. Post-FF.
For 2018 - evaluate usage of connman versus network manager/modem manager for long-term especially for 4G and complex use cases.
Discussed test methodology and packaging for CIAT tests. Schedule a separate a call to discuss with IoT.bzh and Konsulko. Tentatively May 15 after the dev call. Scott, Matt, Matt, Sebastien, Jose, Jonathan should be invited.
New Business:
May 17, 2018
Attendees: Walt, Sebastien, Michael, Stephane, Romain, Jonathan, Matt, Tiejun
User profiles to allow authorized users to configure Wifi and BT
Support for additional wifi dongles and modes. Currently station mode only.
For 2018 - evaluate usage of connman versus network manager/modem manager for long-term especially for 4G and complex use cases.
Discussed test methodology and packaging for CIAT tests. Schedule a separate a call to discuss with IoT.bzh and Konsulko. Tentatively May 15 after the dev call. Scott, Matt, Matt, Sebastien, Jose, Jonathan should be invited.
New Business:
May 3, 2018
Attendees: Walt, Jan-Simon, Romain, Michael, Matt, Sebastien, Jonathan
User profiles to allow authorized users to configure Wifi and BT
Support for additional wifi dongles and modes. Currently station mode only.
For 2018 - evaluate usage of connman versus network manager/modem manager for long-term especially for 4G and complex use cases.
New Business:
Discussed test methodology and packaging for CIAT tests. Schedule a separate a call to discuss with IoT.bzh and Konsulko. Tentatively May 15 after the dev call. Scott, Matt, Matt, Sebastien, Jose, Jonathan should be invited.
April 19, 2018
Attendees:Walt, Jan-Simon, Sebastien, Jonathan, Romain, Michael
User profiles to allow authorized users to configure Wifi and BT
Support for additional wifi dongles and modes. Currently station mode only.
For 2018 - evaluate usage of connman versus network manager/modem manager for long-term especially for 4G and complex use cases.
New:
Code reviewers for EG: Matt, Romain, Kusakabe, Scott, Jonathan
April 5, 2018
Attendees: Walt, Jan-Simon, Sebastien, Romain, Dennis, Stephane, Jonathan, Matt, Michael
User profiles to allow authorized users to configure Wifi and BT
Support for additional wifi dongles and modes. Currently station mode only.
For 2018 - evaluate usage of connman versus network manager/modem manager for long-term especially for 4G and complex use cases.
New:
Code reviewers for EG: Matt, Romain, Kusakabe, Scott, Stephane
March 22, 2018
Attendees: Walt, Romain, Jonathan, Matt
User profiles to allow authorized users to configure Wifi and BT
Support for additional wifi dongles and modes. Currently station mode only.
For 2018 - evaluate usage of connman versus network manager/modem manager for long-term especially for 4G and complex use cases.
New:
March 8, 2018
Attendees: Walt, Jan-Simon, Michael, Sebastien, Romain, Jonathan
New:
January 25, 2018
Attendees: Walt, Jan-Simon, Sebastien, Stephane, Michael, Christian
CES Demo
Kingfisher Advanced board proposed to be used. Late October deliver expected from Shimafuji. IoT.bzh will start looking at their board to verify the in BSP and connectivity to the external modules.
11/2 - Kingfisher boards arrived in Yokohama. BSP in progress at IoT.bzh, but they are having issues because Cogent did a “proof of concept” BSP that is a fork of an older Renesas BSP and there is no easy way to port if to the current upstream Renesas BSP.
11/16 - Ongoing work in Yokohama
11/30 - BSP being sorted out. Kingfisher being merged to master in meta-renesas-rcar-gen3 but there are a quite a few (60+) patches to be merged. Konsulko does not have the board, except for Scott. Backup plan to use ULCB with a bunch of USB dongles would still be a problem with BT audio for telephony.
Vehicle Signaling
-
11/2 - Work delayed because Romain was pulled into Window Manager effort. Concern that there is not a set of reference CAN messages or an reference app to make available as part of the release. Walt would like to get the code into EE to encourage people to start using it and we can fix any defects as they are found.
11/16 - No progress. Romain still working on Window Manager, HMI, XDG, etc effort.
11/30 - Romain did some work on the signal composer. Need to create a list of features and test apps available for EE.
12/14 - agl-service-signal-composer repo created. Romain pushed his code there. Need to make a recipe for RC5 to make it available for EE. Documentation will be updated on the web site as well.
Telephony Updates
Initial implementation in DD with reference phone app.
EE improvements
Move to a standalone service binding
Build out feature set for telephony (multipart call, phone book, reliability)
Update 10.8.:
Update to v2 and aligning verbs used between bindings.
Work on moving to a standalone binding.
Looking into phone book profile
Update 8/24
Telephone binding now standalone.
Working on verb syntax for bindings. Will discuss at the F2F in Yokohama next week.
Phone book and contact database investigations ongoing. Matt P. looking at best practices in other spaces (Android, etc.)
9/7 - No update
9/20 - Looking at regressions introduced in the pyro update to master.
10/5 - Matt looking at asynchronous events to the telephone QML app. Having issues with the SCO voice connection for HFP so Matt is working with Vayu rather ULCB.
11/2 - Everything is in except the cleanup to make it standalone. Asynchronous event handing code is in progress. Talked about whether/ how to make it generic in such a way to make it work with
GUI toolkits other than Qt, but that is a much bigger job.
11/16 - Work completed on asynchronous event handling for telephony.
12/14 - SCO issues with KF persist. See SPEC-1175 for any updates.
Bluetooth profiles -
Phone book/contacts
10/5 - See above.
11/1 - On hold.
11/30 - On hold.
12/14 - On hold
New:
February 8, 2018
Attendees: Walt, Jan-Simon, Sebastien, Stephane, Michael, Christian, Romain,
New:
January 11, 2018
Attendees: Upcoming Meeting
Cancel due to CES.
Pre-2018 Meeting minutes