Set up a docker network. Change the subnet to whatever you want.

docker network create \
    --driver=bridge \
    --subnet=10.0.1.0/24 \
    --gateway=10.0.1.1 \
    wazuh_npm

Clone and enter the Wazuh repo.

git clone https://github.com/wazuh/wazuh-docker.git -b v4.8.1 && \
cd wazuh-docker/single-node

Generate the Certificates

docker-compose -f generate-indexer-certs.yml run --rm generator

Now in, the docker-compose file, add static IPs to each container. I like setting a container name as well.

# single-node/docker-compose.yml
services:
    wazuh.manager:
        image: wazuh/wazuh-manager:4.8.1
        hostname: wazuh.manager
        container_name: wazuh-manager
        networks:
            wazuh_npm:
                ipv4_address: 10.0.1.30
        . . .
    wazuh.indexer:
        image: wazuh/wazuh-indexer:4.8.1
        container_name: wazuh-indexer
        hostname: wazuh.indexer
        networks:
            wazuh_npm:
                ipv4_address: 10.0.1.31
        . . .
    wazuh.dashboard:
        image: wazuh/wazuh-dashboard:4.8.1
        container_name: wazuh-dashboard
        hostname: wazuh.dashboard
        networks:
            wazuh_npm:
                ipv4_address: 10.0.1.32
        . . .
    app:
      image: jc21/nginx-proxy-manager:latest
      networks:
          wazuh_npm:
              ipv4_address: 10.0.1.20
networks:
    wazuh_npm:
        name: wazuh_npm
        external: true

Whatever IP you assign the Wazuh Dashboard needs to be put into single-node/config/wazuh_dashboard/opensearch_dashboards.yml

# single-node/config/wazuh_dashboard/opensearch_dashboards.yml
server.host: 10.0.1.32
server.port: 5601
. . .

Grab the certificate files generated for the dashboard and the root ca. You'll need to change the permissions to copy them first.

config/wazuh_indexer_ssl_certs/wazuh.dashboard.pem
config/wazuh_indexer_ssl_certs/wazuh.dashboard-key.pem
config/wazuh_indexer_ssl_certs/root-ca.pem

Start the containers.

docker-compose up -d

Go to the NPM web interface, import the SSL certificates, and create a proxy host.

IP: http://10.0.1.32:5601
Enable websockets support.

Should be good.

Use this tutorial at your own risk. It's not my fault if you brick your device.

Notable Identifiers on the board
SN-NG-ZBP-01
WW220300
ZB Bridge-P

Front of board. A 5 pin header has been soldered on.

Back of board. I did some probing on the other pads just for fun, so ignore their ugliness.

Note: The USB port on the bridge will no longer work for data after this flash.

Hold down the button on the Arduino, plug it in, then release the button to wipe the Arduino. Unplug it before connecting it to the bridge, of course.

Add a udev rule to allow user access to the port. Or run everything with sudo if you're feeling frisky.

sudo /etc/udev/rules.d/01-ttyusb.rules

SUBSYSTEMS=="usb-serial", TAG+="uaccess"

Reboot or reload udev rules

sudo udevadm control --reload

sudo udevadm trigger

Connect the nano via USB. Make sure the mini-USB cable you use is capable of data transfer. Try the example blink sketch to make sure.

use dmesg to make sure the OS sees and attaches the Arduino

sudo dmesg -w

Note the attached port ttyUSB0. You'll need that in the next step.

Go to the Tasmota Web Flash Tool. I used Chrome. Select this firmware.

Click connect, and choose the USB device you saw in dmesg.

If the Arduino is properly connected, it will start the flash.

Once it's done, close the page and disconnect everything.

Connect a micro-USB to the bridge, wait for the lights to flash, and search for a WiFi access point.

go to 192.168.4.1 in your browser. Choose your WiFi network and log in.

After it connects, I'll give you the address assigned by your router.

Reconnect to your regular WiFi network. In the web interface go to "Configuration" > "Auto-configuration" and select "Sonoff ZBPro TCP" and apply it. The config without "TCP" means the bridge will manage it's own zigbee connections. We'd rather HomeAssistant do that.

After the reboot, go to "Consoles" > "Console" and look for

Starting TCP server on port 8888

Now switch over to Home Assistant.

Go to integrations and click "Add Integration". Search for Zigbee.

Make sure you use "Zigbee Home Automation" and not "Add a Zigbee Device"

Click Proceed

Select "Enter Manually" then Submit

Select Radio Type "ZNP".

for Serial Port Settings, type in socket://10.10.10.153:8888 using whatever IP was assigned. Leave the Port speed, and select "software".

Select "Create a network"

Now, after a few minutes, a "Success" modal will appear along with all unpaired Zigbee devices HA has found. Do not add anything other than "Zigbee Coordinator" at this time.

In HA go to Settings >Devices and services > Zigbee Home Automation
click "0 devices"

Then "ADD DEVICE" at the bottom right. Follow the prompts.

And we're done.

fix:

sudo rm -rfv /etc/pacman.d/gnupg

sudo pacman-key --init

sudo pacman-key --populate archlinux

sudo pacman-key --populate manjaro

sudo pacman -Sy gnupg archlinux-keyring manjaro-keyring

sudo pacman -Syyu

Search for Tab Groups Save and Sync

Change to Enabled

Restart Chrome

Create a new Tab Group

Right-click the group name and select Save Group

The group will now save to the Bookmarks Toolbar

Follow the same process on all other computers, and now the group will stay synced on those devices, and persist across sessions.

When you open new tabs and have Chrome open on more than one device with this setup, the tab will also open on the other devices.

Keep in mind, that the process can be slow, and for me takes about 45 seconds for this to update across devices.

Doesn't work on Android chrome it seems. Bookmarking chrome://history/syncedTabs is a good shortcut I've found to have front and center for mobile.

Enjoy!

U4 - TCA6416RTWR - (the only large ic on the power board)

This chip handles IO Expansion for all the buttons.

Test points to tap:

// ON THE POWER BOARD
13 - 5v from the USB
19 - LB
20 - RB
21 - A
22 - X
23 - Y
28 - LED through Q3
39 - Share

// ON THE MCU BOARD
63 - LStick Y
65 - RStick Y
67 - RTrigger
68 - LTrigger
112 - RStick X
DT - Left Sick X

Right Stick Points

Left Stick Points - Direct Tap

Power Board

Test points to pull high

TP113 Enables TRG+ for the left and right trigger via TLV707

TP36 Enables the 1.8v Rail needed for the analog sticks va MP1476L

ssh into unraid

cd /mnt/user/appdata/mariadb-official/config

nano my.cnf

paste in

[mysqld]
innodb_force_recovery=1

exit

chmod 0444 my.cnf

restart the docker container.

Fix whatever broke

specifically, I broke a table in my nextcloud database

in the unraid ssh session, attach to the mariadb container

docker exec -it MariaDB-Official /bin/bash

mysqlcheck is a feature built into mariadb, and is a lot faster

mysqlcheck -u nextcloud -p --auto-repair --check --all-databases

delete the my.cnf file

done :)

1. Create a directory called umaineros2and cd into it. Paste the code below into a new file "Dockerfile"

2. build it

   docker build -t umaineros2 .

3. Run the container detached docker

   run -itd --privileged --name umorosworkspace umaineros2 /bin/bash

4. Check if the container is up with

   docker ps -a

5. You can connect to the container's shell at any time via

   docker exec -it umorosworkspace bash

6. detach from the shell with the key combo CTRL+A+D

FROM ros:foxy-ros-core-focal

# Global PATH 
ENV PIP_NO_CACHE_DIR=off \
    PIP_DISABLE_PIP_VERSION_CHECK=on \
    PIP_DEFAULT_TIMEOUT=100 \
    VENV_PATH=/opt/venv  \
    ROS_DOMAIN_ID=4 \
    ROS_DISTRO=foxy \
    POETRY_PATH=/opt/poetry \
    VENV_PATH=/opt/venv \
    POETRY_VERSION=0.12.17 \
    ROS2_WS=/opt/ros2_ws \
    PATH="/opt/poetry/bin:$PATH" \
    LC_ALL=C.UTF-8 \
    LANG=C.UTF-8

# install bootstrap tools
RUN apt-get update && apt-get install --no-install-recommends -y \
    build-essential \
    curl \
    git \
    python3-colcon-common-extensions \
    python3-colcon-mixin \
    python3-rosdep \
    python3-vcstool \
    python3-pip \
    python3-argcomplete \
    python3.8-venv \
    && rm -rf /var/lib/apt/lists/*

# bootstrap rosdep
RUN rosdep init && \
    rosdep update --rosdistro $ROS_DISTRO

# setup colcon mixin and metadata
RUN colcon mixin add default \
      https://raw.githubusercontent.com/colcon/colcon-mixin-repository/master/index.yaml && \
    colcon mixin update && \
    colcon metadata add default \
      https://raw.githubusercontent.com/colcon/colcon-metadata-repository/master/index.yaml && \
    colcon metadata update

# install ros2 packages
RUN apt-get update &&  apt-get install -y --no-install-recommends \
    ros-foxy-ros-base=0.9.2-1* \
    ros-foxy-desktop \
    && rm -rf /var/lib/apt/lists/*
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y ros-foxy-desktop

# install Poetry
RUN curl -sSL https://install.python-poetry.org | POETRY_HOME=/opt/poetry python3 - \
    && poetry --version \
    && python3 -m venv $VENV_PATH \
    && poetry config settings.virtualenvs.create false \
    && rm -rf /var/lib/apt/lists/*

# setup workspace
RUN mkdir -p $ROS2_WS/code \
    && mkdir $ROS2_WS/Lepton
WORKDIR $ROS2_WS
RUN echo "source /opt/ros/$ROS_DISTRO/setup.bash" >> /root/.bashrc 

ENTRYPOINT ["/ros_entrypoint.sh"]
CMD ["bash"]

This device uses the Slipstream Wireless Dongle, and I won't be. I'm figuring this out as I go, and adding a wireless dongle (that neither program has worked on yet) will add a layer of complexity to something I already don't know how to do. For now, USB only.

1/2/23: As you can see in the "USB Description Overview w/ lsusb" section, I've managed to map out my best estimation of what each nibble does. I am working solely on ckb-next integration for LED control at this stage. The unfortunate issue I face is that I was hoping I could build off of the bragi protocol already implemented in ckb-next, but it looks like it isn't compatible.

1/3/23: When I first started out, I focused on the packets sent to control functionality. With the new info that it isn't bragi compatible, I have to decipher the initiation packets sent when iCUE first recognizes the headset. Yay me.

References:

USB.org - HID 1.1 Specsheet

How to setup Wireshark for the purpose of USB packet capture on liquidctl wiki

beyondlogic: USB in a NutShell

liquidctl Wiki Techniques for analyzing USB protocols

A Reddit post outlining the reverse engineering of a Corsair Keyboard

ckb-next wiki on the Corsair Protocol

liquidctl wiki on the Corsair Commander Core

FFR

Device ID: 0x0a3d

dev_address determined from the "GET DESCRIPTOR Response DEVICE" Packet, which is like the fourth one sent in in Wireshark, depending on how many USB devices are passed to the VM. For me, #1 was the VirtualBox mouse driver.

Wireshark Filter:

((((usb.device_address == 2)) && (usb.data_len == 64)) ) && (usb.irp_info.direction == 0x0)

Bash output in OSS-Code looks pretty when put in a JSON file.

USB Description Overview w/ lsusb

lsusb -v -d 1b1c:0a3d verbose output for the specific device

Bus 001 Device 008: ID 1b1c:0a3d Corsair CORSAIR VIRTUOSO SE USB

1b1c:0a3d = Vendor ID, unique to manufacturer (usually)

1b1c:0a3d = Product ID, unique to device

Ref: USB HID Appendix

Device Descriptor

USB device required by OS to explain descriptor. Not all fields are required.

idVendor 0x1b1c Corsair

iProduct 2 CORSAIR VIRTUOSO SE USB

Configuration Descriptor

MaxPower 150mA

Interface Descriptor

bInterfaceProtocol 0 "none," not a keyboard or mouse

The headset has 4 interfaces starting at 0. Interface 3 is the HID device to control the LEDs and other settings.

Endpoint Descriptor

The host computer initiates everything. Interrupts in USB are seen by the host at a certain poll rate and know, based on this descriptor, what that interval is, and what packet size is expected. In this case, 64 bytes.

bEndpointAddress 0x81 EP 1 IN Endpoint 1 IN, Most significant bit sent 8

The host is telling the device to send it data.

bEndpointAddress 0x01 EP 1 OUT Endpoint 1 OUT, Most significant bit sent 0

The host is giving the device stuff to do.

Frame Analysis: Initialization

Raw Frame

0000   [1b 00] [e0 a6 c5 1d 82 91 ff ff] [00 00 00 00] [09 00]
0010   [00] [01 00] [02 00] [01] [01] [40 00 00 00] {[02] [08] [(02 11 00
0020   00 00 00 00 00 00 00 00 00 00 00) 00 00 00 00 00
0030   00 00 00 00 00 00 00 00 00 00 00] [00 00 00 00 00
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050   00 00 00 00 00 00 00 00 00 00 00]}

91 bytes on the wire, this specific frame is the first interrupt_out sent to the headset.

I broke the bytes up in square brackets by function, according to Wireshark. Curly brackets indicate the HID data. I'll break down each square bracket by field name indicated in Wireshark.

1. usbpcap_header_len

2. irp_id

3. usbd_status

4. function

5. irp_info

6. bus id

7. device address

8. endpoint

9. transfer_type

10. packet data length

11. report id

12. vendor data

13. padding (only first 15 bytes have been observed to be used)

14. not specified

Only items 11, 12, and 13 are relevant HID data.

Initialization Frames

There are 33 of these.... Hopefully they'll help decipher the Interrupt_out mappings.

HID Data Decoding

INTERRUPT_OUT Mapping

Pkt  Purpose            Out    IN
[0]  Report ID          02     01
[1]  Vendor Data        08     00
[2]  Commands                  Echo
[3]  Feature Select
[4]  Data (1)
[5]  Data (2)
[6]  Unknown (2)
[7]  Unknown (3)
[8]  Red
[9]  Mic (1)? 
[10] Mic (2)
[11] Green 
[12] Charge LED
[13] Mic (3)
[14] Blue

[2] Commands

Possibly indicates what feature of the headset is being modified

*** Seen in Initialization ***
01
02
0d Sleep Enabled Status
09
08
05

*** Seen while expirementing with settings ***
06 RGB
0e Sleep wait time

*** Seen Ocasionally with no user input ***
12

[3] Feature Select

Indicates the feature being written to/read from

00 LED
02 Brightness
0d Sleep toggle 
0e Sleep time

[4] [5] Data Bytes

I'm pretty sure these two bytes are the values passed by whatever setting is altered. I have only seen them change when changing the sleep time and brightness.

Case of the Battery: I started a capture when I knew the headset wasn't fully charged. The reply packets indicate that Data (2) was the only byte that changed slowly over a few minutes. "XX 03" seems to indicate that "XX" (data 1) is the battery level, and "03" (data 2) maybe indicates that data 1 is outputting battery info. TODO: VERIFY SETTING INDICATOR DURING CHARGE

09 00     Mic LED color
XX 03     Battery Level

XX = byte changes

[9][10][13]Microphone

Mic (2)    ff
Mic (3)    00
Microphone is Muted and "Disabled LED When Mic is Active" does nothing.
Mic LED is RED

Mic (2)    00
Mic (3)    ff
Microphone is not Muted and "Disabled LED When Mic is Active" is disabled.
Mic LED is Green

Mic (2)    00
Mic (3)    00
Microphone is not Muted and "Disabled LED When Mic is Active" is enabled.
Mic LED is off

Mic (2)    ff
Mic (3)    ff
unknown
Mic LED is yellow


I think Mic (1) indicates that the Green RGB contol byte is being used to control the charge LED rather than the main logo LEDs. "e1"

Data (1) is 09. Also, the button on the microphone controls the mute/unmute bytes.

Microphone LED is also full RGB which can be observed when switching the headset to wireless mode and may be independently controllable, but iCUE won't let users change this.

Features without dedicated bytes

Sleep Toggle and Wait Time

Sleep on, 2 packets. Sleep off, 1 packet. Change sleep time, 2 packets.

When sleep is turned on, the ("when to start" setting in iCUE) sleep time must be re-assigned every time. The two Data Bytes change when the sleep time value has been changed. I think the Setting Indicator byte flips to 0d to toggle the actual sleep function since all other values are zeros at this point, and it is present for the first sleep-on packet and the only sleep-off packet. The byte goes to 0e only after the first sleep-on packet to reassign the sleep time to the newly re-enabled sleep function.

Order of operations

1. Turn sleep on in iCUE

   Packet 1 = Feature Select 0d , Data Bytes ff

   Packet 2 = Feature Select 0e , Data Bytes specify the when to start time

2. Turn sleep off in iCUE

   Packet 1 = Feature Select 0d , Data Bytes 00

Charge indicator LED

When the headset is connected VIA USB and fully charged, this led flashes. The speed at which interrupt-out packets are sent corresponds to the speed of the LED pulsing. When it's solid green, it sticks to 80. This LED is also full RGB which can be observed when switching the headset to wireless mode and may be independently controllable, but iCUE won't let users change this.

This byte is the dedicated brightness of the charge led.

You can send datum to this byte to change the intensity, but it is overwritten by, assumably, the firmware.

Software Brightness control packets

Six packets are sent to the device when using the dedicated brightness slider.

Logo-LED

No contention here. Pretty obvious which bytes control the primary LED just by toggling them.

Software only

There are no packets sent from the host for the following functions: Sidetone and its volume slider, 7.1/Stereo, lighting link presets, EQ presets, Voice Prompts, Battery indicator in the status bar.

• Enable S3 Deep Sleep

  • BIOS

    • Disable TPM, SGX, SMM, and

    • Absolute On the Power =- lid turns on machine

    • disable early sign of life

• /etc/default/grub

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ibt=off  mem_sleep_defualt=deep intel_pstate=active"
  

• /etc/bluetooth/main.conf

  • Experimental=true

Software

libinput xorg-xinput xf86-input-libinput xdotool

• powertop

  • powertop --calibrate

• cpupower as service

• AURs

  • mkinitcpio-firmware

    • get rid of the annoying 'WARNING: Possibly missing firmware for module:' messages

  • v4l2-ctl

    • webcam

• KDE

  • add a 5 second delay to the .desktop file of all applications that autostart

    • Exec=sleep 5 && /usr/bin/protonmail-bridge

Notes

"Kernels between 5.17 and 5.18.3 (included) can not suspend properly when Bluetooth is enabled" - "Bug fixed in linux-5.19.2" link

MATLAB is selecting SOFTWARE OPENGL rendering.
License checkout failed.
License Manager Error -9
The hostid of your computer ("000000000") does not match the hostid of the license
file (0000000000). 
To run on this computer, you must run the Activation client to reactivate your license.

Troubleshoot this issue by visiting: 
https://www.mathworks.com/support/lme/R2022a/9

Diagnostic Information:
Feature: MATLAB 
License path: /home/nathan/.matlab/R2022a_licenses/license_Price-Desktop-Arch-Image_00000_R2022a.lic:/home/nathan
/.local/share/MATLAB/R2022a/licenses/license.dat:/home/nathan/.local/share/MATLAB/R2022a/licenses 
Licensing error: -9,57.

So, the first thing we need to do is delete the old license file.

rm -rf /home/nathan/.matlab/R2022a_licenses/license_Price-Desktop-Arch-Image_00000_R2022a.lic

Now run the GUI version.

matlab

you should be greeted with:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1670801030787/Ox7MmxHsG.png align="middle")

Just click next, log in with your MathWorks account, and success.

These errors are hardware related, and I probably shouldn't ignore them. Most likely from a PCIe card that isn't seated properly or something. Either way, I want to stop filling my Syslog with several gigs of this every day on a machine I don't care about. To suppress them, add the kernel parameter

append initrd=/bzroot pci=noaer

to your grub bootloader or, in the case of this system, syslinux configuration.

zstd: error 25 : Write error : No space left on device (cannot write compressed block)  
bsdtar: Write error 
bsdtar: Write error 
==> ERROR: Image generation FAILED: sort reported an error 
error: command failed to execute correctly

So I just deleted all of the .img files in /boot

sudo rm /boot/*.img

Now install the LTS kernel. If you reboot before installing the new one, your system will not boot.

sudo pacman -Syu linux-lts linux-lts-headers

If using VirtualBox, you need to swap its kernel modules to match the new LTS kernel before you can remove the Linux package.

sudo pacman -S virtualbox-host-dkms

Allow the replacement.

virtualbox-host-dkms and virtualbox-host-modules-arch are in conflict. Remove virtualbox-host-modules-arch? [y/N] y

Now remove the linux and linux headers packages

sudo pacman -R linux linux-headers

Finally, update your bootloader.

sudo grub-mkconfig -o /boot/grub/grub.cfg

Download the pico SDK from the official GitHub into your chosen directory. I don't like looking at it, so I put it in a hidden folder.

mkdir ~/.picob && cd ~/.pico
git clone https://github.com/raspberrypi/pico-sdk.git

Add the SDK to your PATH. I like using zsh instead of bash.

nano ~/.zshrc

append the following lines to the bottom of the file

export PICO_SDK_PATH="/home/nathan/.pico/pico-sdk"

Log out and back in to update the PATH or

. ~/.zshrc

add sub-modules

cd ~/.pico/pico-sdk/
git submodule update --init

Picotool (optional)

download code, compile, move to local bin

cd ~/.pico
git clone https://github.com/raspberrypi/picotool.git
cd picotool
mkdir build && cd build
cmake ../
make
sudo cp picotool /usr/local/bin/

Pico-extras (optional)

download code, compile, and add to path.

cd ~/.pico
git clone https://github.com/raspberrypi/pico-extras.git
nano ~/.zshrc

append the following lines to the bottom of the file

export PICO_EXTRAS_PATH="/home/nathan/.pico/pico-extras"

Log out and back in to update the PATH or

. ~/.zshrc

Compile the "blink" example

cd ~/Downloads
git clone https://github.com/raspberrypi/pico-examples
cd pico-examples
mkdir build && cd build
cmake ..
cd blink
make

BOOTSEL Mode

Hold the BOOTSEL button (White color button near the micro USB connector) located on the Pico board while connecting the Pico to the computer.

Find and mount the pico

lsblk -f

look for something like

sde
└─sde1 vfat FAT16 RPI-RP2 0009-4A70`

/dev/sde is the device /dev/sde1 is a filesystem on the device.

sudo mkdir /mnt/usb && sudo chown $USER:$USER /mnt/usb
sudo mount /dev/sde1 /mnt/usb

Copy over the "blink.uf2" file to the pi.

cp blink.uf2 /mnt/usb

It should immediately start blinking.

CONT. for ECE 101

Download the three multimeter files from the course website. Use RMB on each link and select "Save as...". I would include wget/curl commands, but those hardlinks could change. After you download them, copy them to the adc_console directory.

cp adc_console.c digits.c CMakeLists.txt ~/Downloads/pico-examples/adc/adc_console/

Remove the prior builds and compile

cd ~/Downloads/pico-examples
rm -rf build
mkdir build && cd build
cmake ..
cd adc/adc_console
make

put the pi in BOOTSEL mode and copy over .uf2 as shown before.

sudo cp adc_console.uf2 /mnt/usb

Monitor the serial output

There are several ways to do this. I like using screen, but you can use a GUI like Putty or a command line tool like minicom. The first few steps to identify the pico serial interface will still be needed to use the other methods.

First, check the kernel message buffer (basically a system log) for info relating to the pico

sudo dmesg

the output to look for:

[169801.734603] usb 5-1: USB disconnect, device number 4
[169801.735187] device offline error, dev sde, sector 260 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 2
[169801.735195] Buffer I/O error on dev sde1, logical block 259, lost async page write
[169802.064671] usb 5-1: new full-speed USB device number 5 using xhci_hcd
[169802.222607] usb 5-1: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00
[169802.222615] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[169802.222617] usb 5-1: Product: Pico
[169802.222619] usb 5-1: Manufacturer: Raspberry Pi
[169802.222621] usb 5-1: SerialNumber: E66098F29B400D32
[169802.285360] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
[169802.285388] usbcore: registered new interface driver cdc_acm
[169802.285391] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

specifically, cdc_acm 5-1:1.0: ttyACM0: USB ACM device. /dev/ttyACM0 is the port we can use to talk to the pico.

sudo screen /dev/ttyACM0 115200

To end the session, press Ctrl+A followed by K. Alternatively, press Ctrl+A, type :quit and confirm it by pressing Enter.

With that, you should be connected. As you can see from the screenshot, my multimeter (which only has the pico plugged in - no power supply) is reading 0.02. This shows that I need to calibrate the meter.

add

export PATH=~/path/to/thing:$PATH

to the end of ./zshrc

Logout and back in to update or

. ~/.zshrc