Over a week after my first post and I was still without a working 64mp camera. The old method of running a script to install drivers still reported the same error, and the entry that used to be in my /boot/config.txt file wasn’t helping.
[all]
dtoverlay=arducam_64mp
I went back to look at the arducam forums and came across this post and found that when they went from the custom kernel module install to the standard module install they’ve changed from using an underscore to a hyphen:
[all]
dtoverlay=arducam-64mp
Now after booting, my camera is correctly recognized. The delay and lack of obvious information on their site has been frustrating, but at least I’m up and working and shouldn’t need to do anything special with further apt updates.
I updated the software on my development machine this morning without thinking too much about it. After doing so, I checked my program that uses the camera to see if it was running properly. I’ve got an Arducam64mp camera that I’m using on that machine, and often when the kernel gets updated I need to reinstall the kernel drivers from Arducam. They have a script, so normally it runs easily enough.
wim@WimPi4-Dev:~ $ sudo ./install_pivariety_pkgs.sh -p 64mp_pi_hawk_eye_kernel_driver
=================================================
Hardware Revision: d03114
Kernel Version: 6.1.19-v8+
OS Codename: bullseye
ARCH: aarch64
=================================================
kernel:6.1.19-v8+
--2023-03-21 10:36:25-- https://github.com/ArduCAM/Arducam-Pivariety-V4L2-Driver/releases/download/install_script/64mp_pi_hawk_eye_kernel_driver_links.txt
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/353945933/a0487b40-ef2c-4923-b366-3e8d0b6f0c88?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230321%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230321T173626Z&X-Amz-Expires=300&X-Amz-Signature=f28c85b9e602c3789a04e891e7a91d43a0dd89759e7297b888093b54fee6670d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=353945933&response-content-disposition=attachment%3B%20filename%3D64mp_pi_hawk_eye_kernel_driver_links.txt&response-content-type=application%2Foctet-stream [following]
--2023-03-21 10:36:26-- https://objects.githubusercontent.com/github-production-release-asset-2e65be/353945933/a0487b40-ef2c-4923-b366-3e8d0b6f0c88?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230321%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230321T173626Z&X-Amz-Expires=300&X-Amz-Signature=f28c85b9e602c3789a04e891e7a91d43a0dd89759e7297b888093b54fee6670d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=353945933&response-content-disposition=attachment%3B%20filename%3D64mp_pi_hawk_eye_kernel_driver_links.txt&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.108.133, 185.199.109.133, 185.199.110.133, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.108.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11382 (11K) [application/octet-stream]
Saving to: ‘64mp_pi_hawk_eye_kernel_driver_links.txt’
64mp_pi_hawk_eye_kernel_driver_links.txt 100%[======================================================================================>] 11.12K --.-KB/s in 0.001s
2023-03-21 10:36:26 (15.6 MB/s) - ‘64mp_pi_hawk_eye_kernel_driver_links.txt’ saved [11382/11382]
Cannot find the corresponding package, please send the following information to support@arducam.com
Hardware Revision: d03114
Kernel Version: 6.1.19-v8+
Package: 64mp_pi_hawk_eye_kernel_driver -- bullseye-arm64-v5
You are using an unsupported kernel version, please install the official SD Card image(do not execute rpi-update):
https://www.raspberrypi.com/software/operating-systems/
wim@WimPi4-Dev:~ $ uname -a
Linux WimPi4-Dev 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux
Today, it didn’t fix the problem. The script reports an unknown kernel version. I noticed that it’s reporting kernel version 6, which seemed unusual to me. That’s when I switched to my other Pi that I have most of my long term stuff running.
wim@WimPi4:~ $ uname -a
Linux WimPi4 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux
A major bump in kernel version from 5 to 6 was unexpected. Now I’m left with the decision of either waiting to get the 64mp camera working with the new kernel or switching back to one of the PiCamera Model 3 units I have collected recently. Because this is on my development machine, the camera is less important to me than on some of my other units.
My development pi has had an Arducam 64mp camera connected for my camera software development. I liked the quality of the camera but have at various times been frustrated with the software requirements to use the camera. It’s required both a custom kernel driver and a custom fork of the libcamera software packages. That’s meant that to use the 64mp camera I needed to reinstall the arducam suite after nearly every apt upgrade cycle, and definitely ones where the system kernel got updated.
I spent several days trying to get the remnants of the arducam64mp removed from my development system. I’d even built a fresh sd card image of Raspian Bullseye to make sure that the hardware was all connected and working properly.
In the end the fix was rather simple, if obscure.
First, remove or comment out the dtoverlay line from the /boot/config.txt file and make sure camera auto detect is enabled.
# dtoverlay=arducam-64mp
camera_auto_detect=1
Then run apt install with the –reinstall option for the libcamera packages and the raspberry kernel package.
Then reboot. That should be then allow you to run libcamera-hello and verify that the new camera is working.
I’d found a reference How To Enable RP Cam V2 After Arducam 64MP that didn’t seem to work for getting the V3 wide camera working, perhaps because the focus hardware in the V3 camera made the 64mp think it was active.
I asked the question of how to remove the drivers on the Arducam Forum and then answered my own question.
On to playing with my new Camera Module 3! (I bought the Arducam cases from Amazon because I really liked the fit. The new wide camera protrudes from the front with enough clearance for the focus to function.)
I’ve figured out I can switch between three different modem configurations on the linux system safely. 9001, 9011, and 9003. 9001 gives me qmi_wwan, 9011 gives me rndis_host, and 9003 give me cdc_mbim. RNDIS is the only one that is really plug and play on linux and produces the usb0 interface instead of wwan0. The method I’ve been configuring the device has been to connect to /dev/ttyUSB2 and issuing AT commands. When I have tried PID modes other than the ones I’ve called safe, Linux doesn’t provide /dev/ttyUSB* ports even though the device interfaces are displayed in the lsusb -t output.
Here’s what I get when I issue the command
AT+CUSBPIDSWITCH=9001,1,1
wim@WimPiZeroW-Wim:~ $ lsusb
Bus 001 Device 003: ID 1e0e:9001 Qualcomm / Option SimTech, Incorporated
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
wim@WimPiZeroW-Wim:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 5, Class=Vendor Specific Class, Driver=qmi_wwan, 480M
wim@WimPiZeroW-Wim:~ $ ip -o a
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever
1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever
2: wwan0 inet 169.254.128.15/16 brd 169.254.255.255 scope global noprefixroute wwan0\ valid_lft forever preferred_lft forever
2: wwan0 inet6 fe80::f9:71:4f35:8ef4/64 scope link \ valid_lft forever preferred_lft forever
3: wlan0 inet 192.168.0.63/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0\ valid_lft 5335sec preferred_lft 4660sec
3: wlan0 inet6 2604:4080:1304:8010:57c0:7b33:ef3:3f35/64 scope global dynamic mngtmpaddr noprefixroute \ valid_lft 1766sec preferred_lft 1766sec
3: wlan0 inet6 fe80::2f9e:ceef:76a0:1efa/64 scope link \ valid_lft forever preferred_lft forever
AT+CUSBPIDSWITCH=9011,1,1
wim@WimPiZeroW-Wim:~ $ lsusb
Bus 001 Device 003: ID 1e0e:9011 Qualcomm / Option SimTech, Incorporated
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
wim@WimPiZeroW-Wim:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Communications, Driver=rndis_host, 480M
|__ Port 1: Dev 3, If 1, Class=CDC Data, Driver=rndis_host, 480M
|__ Port 1: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 5, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 6, Class=Vendor Specific Class, Driver=option, 480M
wim@WimPiZeroW-Wim:~ $ ip -o a
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever
1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever
2: wlan0 inet 192.168.0.63/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0\ valid_lft 5371sec preferred_lft 4696sec
2: wlan0 inet6 2604:4080:1304:8010:57c0:7b33:ef3:3f35/64 scope global dynamic mngtmpaddr noprefixroute \ valid_lft 1767sec preferred_lft 1767sec
2: wlan0 inet6 fe80::2f9e:ceef:76a0:1efa/64 scope link \ valid_lft forever preferred_lft forever
3: usb0 inet 192.168.225.59/24 brd 192.168.225.255 scope global dynamic noprefixroute usb0\ valid_lft 43172sec preferred_lft 37772sec
3: usb0 inet6 2607:fb90:8069:ec7e:4a34:bb42:93a9:e27d/64 scope global mngtmpaddr noprefixroute \ valid_lft forever preferred_lft forever
3: usb0 inet6 fe80::b8ef:f02b:c580:1ebc/64 scope link \ valid_lft forever preferred_lft forever
AT+CUSBPIDSWITCH=9003,1,1
wim@WimPiZeroW-Wim:~ $ lsusb
Bus 001 Device 003: ID 1e0e:9003 Qualcomm / Option SimTech, Incorporated
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
wim@WimPiZeroW-Wim:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 3, If 5, Class=Communications, Driver=cdc_mbim, 480M
|__ Port 1: Dev 3, If 6, Class=CDC Data, Driver=cdc_mbim, 480M
wim@WimPiZeroW-Wim:~ $ ip -o a
1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever
1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever
2: wwan0 inet 169.254.175.62/16 brd 169.254.255.255 scope global noprefixroute wwan0\ valid_lft forever preferred_lft forever
2: wwan0 inet6 fe80::b43f:d4a3:f985:4f33/64 scope link \ valid_lft forever preferred_lft forever
3: wlan0 inet 192.168.0.63/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0\ valid_lft 5341sec preferred_lft 4666sec
3: wlan0 inet6 2604:4080:1304:8010:57c0:7b33:ef3:3f35/64 scope global dynamic mngtmpaddr noprefixroute \ valid_lft 1764sec preferred_lft 1764sec
3: wlan0 inet6 fe80::2f9e:ceef:76a0:1efa/64 scope link \ valid_lft forever preferred_lft forever
I have configured the modem to run the way I want with the following commands
There are multiple things I’m trying to understand about networking while running in 9011 mode. It gets a global scope ipv6 address that is reachable, but that address changes on a very frequent but random time. It gets a local ipv4 address that works for traffic over the internet. Obviously the ipv4 address is being converted by NAT between the raspberry and the internet. I don’t seem to have any way of configuring how that works. The post https://www.jeffgeerling.com/blog/2022/using-4g-lte-wireless-modems-on-raspberry-pi had a Built-in AP configuration that was accessible via http. I have run nmap against the internal gateway on my platform and the only port open is DNS.
Today I ran radvdump to listen for router advertisements from the internet and then later looked at my syslog results to see what happened on the network at the corresponding times.
# radvd configuration generated by radvdump 2.18
# based on Router Advertisement from fe80::fca7:efa4:eef4:655b
# received by interface usb0
#
interface usb0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 255;
AdvDefaultLifetime 0;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;
AdvLinkMTU 1500;
prefix 2607:fb90:80ca:7753::ff00:0/0
{
AdvValidLifetime 2;
AdvPreferredLifetime 1;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
}; # End of interface definition
Nov 11 16:11:32 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::fca7:efa4:eef4:655b
Nov 11 16:11:32 WimPiZeroW-Wim dhcpcd[701]: usb0: adding address 5c5a:870:6182:d190:617e:1551:4cea:f6b6/0
Nov 11 16:11:32 WimPiZeroW-Wim dhcpcd[701]: ipv6_addaddr1: Invalid argument
Nov 11 16:11:32 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:80ca:7753::ff00:0/0
Nov 11 16:11:32 WimPiZeroW-Wim dhcpcd[701]: if_route (ADD): File exists
Almost immediately afterwards:
#
# radvd configuration generated by radvdump 2.18
# based on Router Advertisement from fe80::fc89:6dff:fe67:6dde
# received by interface usb0
#
interface usb0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 0;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvLinkMTU 1500;
prefix 2607:fb90:80ca:7753::/64
{
AdvValidLifetime 2;
AdvPreferredLifetime 1;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
RDNSS fd00:976a::9 fd00:976a::10
{
AdvRDNSSLifetime infinity; # (0xffffffff)
}; # End of RDNSS definition
}; # End of interface definition
Nov 11 16:11:33 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::fc89:6dff:fe67:6dde
Nov 11 16:11:33 WimPiZeroW-Wim dhcpcd[701]: usb0: fe80::fc89:6dff:fe67:6dde: no longer a default router
Nov 11 16:11:33 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:80ca:7753::ff00:0/0
Nov 11 16:11:33 WimPiZeroW-Wim dhcpcd[701]: if_route (ADD): File exists
Nov 11 16:11:33 WimPiZeroW-Wim dhcpcd[701]: usb0: deleting default route via fe80::fc89:6dff:fe67:6dde
Nov 11 16:11:34 WimPiZeroW-Wim dhcpcd[701]: usb0: part of Router Advertisement expired
Nov 11 16:11:34 WimPiZeroW-Wim avahi-daemon[240]: Registering new address record for fe80::a3b3:ec14:47de:4692 on usb0.*.
Nov 11 16:11:35 WimPiZeroW-Wim dhcpcd[701]: usb0: expired address 2607:fb90:80ca:7753:ee71:7d12:766:2e98/64
Nov 11 16:11:35 WimPiZeroW-Wim dhcpcd[701]: usb0: part of Router Advertisement expired
Nov 11 16:11:35 WimPiZeroW-Wim dhcpcd[701]: usb0: deleting route to 2607:fb90:80ca:7753::/64
Nov 11 16:11:35 WimPiZeroW-Wim avahi-daemon[240]: Withdrawing address record for 2607:fb90:80ca:7753:ee71:7d12:766:2e98 on usb0.
Nov 11 16:11:35 WimPiZeroW-Wim avahi-daemon[240]: Leaving mDNS multicast group on interface usb0.IPv6 with address 2607:fb90:80ca:7753:ee71:7d12:766:2e98.
Nov 11 16:11:35 WimPiZeroW-Wim avahi-daemon[240]: Joining mDNS multicast group on interface usb0.IPv6 with address fe80::a3b3:ec14:47de:4692.
And a couple of minutes later:
# radvd configuration generated by radvdump 2.18
# based on Router Advertisement from fe80::fc89:6dff:fe67:6dde
# received by interface usb0
#
interface usb0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag on;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 65535;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvLinkMTU 1500;
prefix 2607:fb90:80c8:82f8::/64
{
AdvValidLifetime infinity; # (0xffffffff)
AdvPreferredLifetime infinity; # (0xffffffff)
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
RDNSS fd00:976a::9 fd00:976a::10
{
AdvRDNSSLifetime infinity; # (0xffffffff)
}; # End of RDNSS definition
}; # End of interface definition
Nov 11 16:13:42 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::fc89:6dff:fe67:6dde
Nov 11 16:13:42 WimPiZeroW-Wim dhcpcd[701]: usb0: adding address 2607:fb90:80c8:82f8:b87a:2c7a:ae2e:7e0e/64
Nov 11 16:13:42 WimPiZeroW-Wim avahi-daemon[240]: Leaving mDNS multicast group on interface usb0.IPv6 with address fe80::a3b3:ec14:47de:4692.
Nov 11 16:13:43 WimPiZeroW-Wim avahi-daemon[240]: Joining mDNS multicast group on interface usb0.IPv6 with address 2607:fb90:80c8:82f8:b87a:2c7a:ae2e:7e0e.
Nov 11 16:13:43 WimPiZeroW-Wim avahi-daemon[240]: Registering new address record for 2607:fb90:80c8:82f8:b87a:2c7a:ae2e:7e0e on usb0.*.
Nov 11 16:13:43 WimPiZeroW-Wim avahi-daemon[240]: Withdrawing address record for fe80::a3b3:ec14:47de:4692 on usb0.
Nov 11 16:13:43 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:80c8:82f8::/64
Nov 11 16:13:43 WimPiZeroW-Wim dhcpcd[701]: usb0: adding default route via fe80::fc89:6dff:fe67:6dde
Then it went almost a couple of hours before more changes to the network
Nov 11 18:01:54 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::c1e7:222d:69eb:c90c
Nov 11 18:01:54 WimPiZeroW-Wim dhcpcd[701]: usb0: adding address 5c5a:870:6182:d190:617e:1551:4cea:f6b6/0
Nov 11 18:01:54 WimPiZeroW-Wim dhcpcd[701]: ipv6_addaddr1: Invalid argument
Nov 11 18:01:54 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:80c8:82f8::ff00:0/0
Nov 11 18:01:54 WimPiZeroW-Wim dhcpcd[701]: if_route (ADD): File exists
Nov 11 18:01:55 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::fc89:6dff:fe67:6dde
Nov 11 18:01:55 WimPiZeroW-Wim dhcpcd[701]: usb0: fe80::fc89:6dff:fe67:6dde: no longer a default router
Nov 11 18:01:55 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:80c8:82f8::ff00:0/0
Nov 11 18:01:55 WimPiZeroW-Wim dhcpcd[701]: if_route (ADD): File exists
Nov 11 18:01:55 WimPiZeroW-Wim dhcpcd[701]: usb0: deleting default route via fe80::fc89:6dff:fe67:6dde
Nov 11 18:01:56 WimPiZeroW-Wim dhcpcd[701]: usb0: part of Router Advertisement expired
Nov 11 18:01:56 WimPiZeroW-Wim avahi-daemon[240]: Registering new address record for fe80::a3b3:ec14:47de:4692 on usb0.*.
Nov 11 18:01:57 WimPiZeroW-Wim dhcpcd[701]: usb0: expired address 2607:fb90:80c8:82f8:b87a:2c7a:ae2e:7e0e/64
Nov 11 18:01:57 WimPiZeroW-Wim dhcpcd[701]: usb0: part of Router Advertisement expired
Nov 11 18:01:57 WimPiZeroW-Wim dhcpcd[701]: usb0: deleting route to 2607:fb90:80c8:82f8::/64
Nov 11 18:01:57 WimPiZeroW-Wim avahi-daemon[240]: Withdrawing address record for 2607:fb90:80c8:82f8:b87a:2c7a:ae2e:7e0e on usb0.
Nov 11 18:01:57 WimPiZeroW-Wim avahi-daemon[240]: Leaving mDNS multicast group on interface usb0.IPv6 with address 2607:fb90:80c8:82f8:b87a:2c7a:ae2e:7e0e.
Nov 11 18:01:57 WimPiZeroW-Wim avahi-daemon[240]: Joining mDNS multicast group on interface usb0.IPv6 with address fe80::a3b3:ec14:47de:4692.
Nov 11 18:04:04 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::fc89:6dff:fe67:6dde
Nov 11 18:04:04 WimPiZeroW-Wim dhcpcd[701]: usb0: adding address 2607:fb90:80c3:42cc:11b:d753:e52a:40bb/64
Nov 11 18:04:04 WimPiZeroW-Wim avahi-daemon[240]: Leaving mDNS multicast group on interface usb0.IPv6 with address fe80::a3b3:ec14:47de:4692.
Nov 11 18:04:04 WimPiZeroW-Wim avahi-daemon[240]: Joining mDNS multicast group on interface usb0.IPv6 with address 2607:fb90:80c3:42cc:11b:d753:e52a:40bb.
Nov 11 18:04:04 WimPiZeroW-Wim avahi-daemon[240]: Registering new address record for 2607:fb90:80c3:42cc:11b:d753:e52a:40bb on usb0.*.
Nov 11 18:04:04 WimPiZeroW-Wim avahi-daemon[240]: Withdrawing address record for fe80::a3b3:ec14:47de:4692 on usb0.
Nov 11 18:04:04 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:80c3:42cc::/64
Nov 11 18:04:04 WimPiZeroW-Wim dhcpcd[701]: usb0: adding default route via fe80::fc89:6dff:fe67:6dde
Nov 11 18:29:11 WimPiZeroW-Wim dhcpcd[701]: usb0: failed to renew DHCP, rebinding
Nov 11 18:29:11 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 192.168.225.0/24
Nov 11 18:29:11 WimPiZeroW-Wim dhcpcd[701]: usb0: adding default route via 192.168.225.1
ov 11 19:52:16 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::459a:7427:b0ae:7848
Nov 11 19:52:16 WimPiZeroW-Wim dhcpcd[701]: usb0: adding address 5c5a:870:6182:d190:617e:1551:4cea:f6b6/0
Nov 11 19:52:16 WimPiZeroW-Wim dhcpcd[701]: ipv6_addaddr1: Invalid argument
Nov 11 19:52:16 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:80c3:42cc::ff00:0/0
Nov 11 19:52:16 WimPiZeroW-Wim dhcpcd[701]: if_route (ADD): File exists
Nov 11 19:52:18 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::fc89:6dff:fe67:6dde
Nov 11 19:52:18 WimPiZeroW-Wim dhcpcd[701]: usb0: fe80::fc89:6dff:fe67:6dde: no longer a default router
Nov 11 19:52:18 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:80c3:42cc::ff00:0/0
Nov 11 19:52:18 WimPiZeroW-Wim dhcpcd[701]: if_route (ADD): File exists
Nov 11 19:52:18 WimPiZeroW-Wim dhcpcd[701]: usb0: deleting default route via fe80::fc89:6dff:fe67:6dde
Nov 11 19:52:18 WimPiZeroW-Wim dhcpcd[701]: usb0: part of Router Advertisement expired
Nov 11 19:52:19 WimPiZeroW-Wim avahi-daemon[240]: Registering new address record for fe80::a3b3:ec14:47de:4692 on usb0.*.
Nov 11 19:52:20 WimPiZeroW-Wim dhcpcd[701]: usb0: expired address 2607:fb90:80c3:42cc:11b:d753:e52a:40bb/64
Nov 11 19:52:20 WimPiZeroW-Wim dhcpcd[701]: usb0: part of Router Advertisement expired
Nov 11 19:52:20 WimPiZeroW-Wim dhcpcd[701]: usb0: deleting route to 2607:fb90:80c3:42cc::/64
Nov 11 19:52:20 WimPiZeroW-Wim avahi-daemon[240]: Withdrawing address record for 2607:fb90:80c3:42cc:11b:d753:e52a:40bb on usb0.
Nov 11 19:52:20 WimPiZeroW-Wim avahi-daemon[240]: Leaving mDNS multicast group on interface usb0.IPv6 with address 2607:fb90:80c3:42cc:11b:d753:e52a:40bb.
Nov 11 19:52:20 WimPiZeroW-Wim avahi-daemon[240]: Joining mDNS multicast group on interface usb0.IPv6 with address fe80::a3b3:ec14:47de:4692.
Nov 11 19:52:27 WimPiZeroW-Wim systemd[1]: session-3.scope: Succeeded.
Nov 11 19:52:27 WimPiZeroW-Wim systemd[1]: session-3.scope: Consumed 24.275s CPU time.
Nov 11 19:54:27 WimPiZeroW-Wim dhcpcd[701]: usb0: Router Advertisement from fe80::fc89:6dff:fe67:6dde
Nov 11 19:54:27 WimPiZeroW-Wim dhcpcd[701]: usb0: adding address 2607:fb90:8069:47ff:69ad:1e37:6fb5:7fa0/64
Nov 11 19:54:27 WimPiZeroW-Wim dhcpcd[701]: usb0: adding route to 2607:fb90:8069:47ff::/64
Nov 11 19:54:27 WimPiZeroW-Wim dhcpcd[701]: usb0: adding default route via fe80::fc89:6dff:fe67:6dde
Nov 11 19:54:27 WimPiZeroW-Wim avahi-daemon[240]: Leaving mDNS multicast group on interface usb0.IPv6 with address fe80::a3b3:ec14:47de:4692.
Nov 11 19:54:27 WimPiZeroW-Wim avahi-daemon[240]: Joining mDNS multicast group on interface usb0.IPv6 with address 2607:fb90:8069:47ff:69ad:1e37:6fb5:7fa0.
Nov 11 19:54:27 WimPiZeroW-Wim avahi-daemon[240]: Registering new address record for 2607:fb90:8069:47ff:69ad:1e37:6fb5:7fa0 on usb0.*.
Nov 11 19:54:27 WimPiZeroW-Wim avahi-daemon[240]: Withdrawing address record for fe80::a3b3:ec14:47de:4692 on usb0.
I do not understand why it gets router advertisements that change as frequently as it does, and especially why sometimes it gets a /0 prefix occasionally.
Here is a series of commands I’ve found useful to checking status on the modem
If you have any suggestions to make my networking more stable, I would appreciate any help. When I tried these two PID modes I lost access to the ttyUSB ports and had to connect the device to a windows machine, force install questionable drivers for the device and then issue commands to reset the modem back to a PID mode I could work with. I would also appreciate any information on how to send AT commands to a USB port/device/interface if the operating system didn’t install tty drivers to make it easily accessible.
AT+CUSBPIDSWITCH=9002,1,1
wim@WimPiZeroW-Wim:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 4, If 2, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 4, If 3, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 4, If 4, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 4, If 5, Class=Vendor Specific Class, Driver=, 480M
AT+CUSBPIDSWITCH=9018,1,1
wim@WimPiZeroW-Wim:~ $ lsusb
Bus 001 Device 003: ID 1e0e:9018 Qualcomm / Option SimTech, Incorporated
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
wim@WimPiZeroW-Wim:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 3, If 1, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 3, If 2, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 3, If 3, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 3, If 4, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 3, If 5, Class=Communications, Driver=cdc_ether, 480M
|__ Port 1: Dev 3, If 6, Class=CDC Data, Driver=cdc_ether, 480M
When I bought my sailboat Sola a year and a half ago the hour meter for the diesel engine was nonfunctional. It is an LCD readout on the lower part of the tachometer. In the totality of the boat purchase this was not a major issue for me, but something that I’d like to get fixed to better keep track of engine maintenance.
Recently I had a major problem with my transmission, and the lack of knowledge about the condition of my engine became something I was very aware of while talking with mechanics. I spent a week sitting around in Port Townsend waiting on parts to get my boat fixed and had plenty of time to watch YouTube videos about fixing things on boats. I came across this one related to possibly fixing my hour meter with a $30 part. It explains what appears to be a common problem with Yanmar control panels, the LCD display of the hour meter fails while everything else continues working, including the counter chip in the background. Replacing the LCD panel gets a working counter without losing the underlying data. $30 is inexpensive compared to everything else I was spending to get the boat fully functional again, so I ordered the part. I paid via PayPal and was able to have PayPal specify my delivery address directly which made the purchase process very easy.
Instead of taking the entire panel out of my cockpit, I crawled into the lazarette, unplugged the cable, and removed the four screws holding the tachometer in place. Mine used Torx T10 screws.
Once the tachometer was sitting at my table, it’s held together by three torx T10 screws. After losening the screws, I was able to push on the screws, popping the lens and gasket out of the front of the housing. The lens itself is only held in place by friction.
Here you can see the internals. The upper plate holds the LCD connected by the ribbon cable, and has curved light guides coming towards incandescent lamps on the lower plate, but is primarily clear plastic with an opaque sticker gauge display on the top. The pin from the needle stepper motor protrudes through. I had to pry the needle off the pin with more force than I hoped, but it went back in place afterwards.
Replacement part in antistatic package, existing condition of the tachometer, and me slowly prying the display sticker from the front of the clear plastic.
I wish I’d ordered a replacement for the tachometer lens. It’s been scratched for the entire time I’ve owned it. Not a significant issue, but it would have improved the appearance.
I waited till I had put everything back in place before I started the engine and was quite pleased to see a display. 12,984 is more hours than I expected, but at least now I have a reference going forward.
The original LCD has the numbers LPH3930-2 05215235 printed on the edge, which is useful to recognize for future web searches. Simply based on that I was able to come across references to fixes for tachometers used on other brand engines. I also came across mention of a calibration menu, which might be useful. I noticed that there is a momentary switch button on the back of the unit. I only noticed it when I pressed it by mistake. Searching for “Siemens VDO Tachometer Installation and Operation Instructions for Programmable Tachometer with Hourmeter N 02 012 195” helped me find details on the calibration button itself.
I hate change for change sake. Apple seems to have modified the volume control for music playing on the Lock Screen and I can’t see a good reason for the change.
Music playing via AirPods
While listening to music via AirPods it seems the only way to adjust the volume is to press the physical up/down buttons on the phone.
Music playing via AirPlay on speakers
When music is playing on external speakers the volume control line is visible below the play control.
My cardio workout has me using AirPods with the phone resting horizontally on the machine in front of me. In the past if I needed to adjust the volume I could tap the screen to wake it up, then adjust the volume with the slider. I also had visual feedback as to where the volume was set. With the new layout I have to pick up the phone, press the volume button, and return the phone to its resting location. It may sound like a minimal change but has to do a lot with balance and cadence, plus a much larger chance of dropping the phone.
After writing up my issue yesterday I posted the question on the amazon product details. I received an answer with a link to this page overnight. It references a page with several custom tuning files for their lenses. There did not seem to be a tuning file that matched the 175° FOV lens on the package I got, but there was both a 160° and a 200° version. I downloaded both files and ran a test capture with each. On initial viewing, either will work for my solution. I need to focus the lens to see if there are any noticeable differences.
I got a message about the tuning file being an older version, with pointers on how to convert it to the updated version.
WARN RPiController controller.cpp:43 This format of the tuning file will be deprecated soon! Please use the convert_tuning.py utility to update to version 2.0.
I still need to decide how I want to handle this in my automated photo processing, but having the information is hugely useful.
I’ve been playing with several cameras attached to raspberry pi recently. Getting cameras is easy right now while getting Raspberry Pi is not. I purchased this model from Amazon and have it connected to a Raspberry Pi4. I had to upgrade the unit from running Raspian Buster to Raspian Bullseye to get support for this particular camera.
Amazon Listing
I was doing some searching for red tint problems and fixing them, and it seems to be something that should be able to fix in software. Most of the fixes refer to Jetson Nano, which is not the platform I’m working with, so the fixes don’t align with my platform.
Red Tint Problem on IMX219
I still need to manually focus the lens on this camera. It’s always a frustrating process on a small lens like this because my fingers obscure the view. I’m running with camera_auto_detect=1 while https://www.arducam.com/docs/cameras-for-raspberry-pi/native-raspberry-pi-cameras/8mp-imx219-standard-camera-modules/ recommends modifying /boot/config.txt and setting both camera_auto_detect=0 and dtoverlay=imx219. exiftool reports Camera Model Name : /base/soc/i2c0mux/i2c@1/imx219@10 with the current settings. I’ve verified that using the explicit camera overlay produces the same red tint as well as having exactly the same Model Name in the exif data.
I was able to find the file /usr/share/libcamera/ipa/raspberrypi/imx219.json which may be similar to the ISP files the Jetson platforms were using. I’m still working on the red tint.
I haven’t found anything that significantly annoyed me yet.
When I’m playing music and there’s cover art, it’s now displayed on the Lock Screen, which is nice.
When the cover art is missing, the controls are now at the bottom of the screen. Each time I see them there I start to rotate my phone, thinking I’ve picked it up upside down.
I’m sure I’ll get used to the new layout. I find this problem funny, at least today.
I have several Raspberry Pi around my apartment in various states of development projects running different versions of Raspian. I’ve been playing with GPSD recently and want the services to be transparently available on each Pi without having to connect directly via a USB port. It turns out that making it work is easy, but obscure.
On my machine that has the GPS plugged into the USB port I need to change the /lib/systemd/system/gpsd.socket file to allow the socket to be visible on the network. On my Raspian Buster machine, it originally looked like this
I was able to test that it was working properly by running the command gpsmon WimPi4:2497 on the remote host. WimPi4 is the hostname of my machine with the GPS installed.
On the machines I wanted access to the GPS, I modified the file /etc/default/gpsd by adding an entry in the DEVICES section to make the file below.
# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="gpsd://WimPi4"
# Other options you want to pass to gpsd
GPSD_OPTIONS=""
# Automatically hot add/remove USB GPS devices via gpsdctl
USBAUTO="true"
With the changes to the gpsd configuration I was able to run cgps or gpsmon on the client machines without requiring an argument. The client programs are connecting the local daemon, which is then connecting to the machine with the gps receiver running gpsd.
WimsWorld 