fatfurrycat
commented
5 years ago Given that a lot of people seem to be having issues with slow write speed errors, it might be worth collecting data on which combinations work, and which don't. So, here's my config, which I've been using for the last 4 days (and over 600 miles of driving), where I'm not seeing any errors:
RHD UK Model 3 Performance Tesla software version: 2019.32.11.1 d39e85a Raspberry Pi Zero W (with PiHut CPU heatsink) Transcend 256GB micro SD card (https://www.amazon.co.uk/Transcend-256GB-microSDXC-Memory-Adapter/dp/B07N31KRZL) Installed from teslausb-buster-20190922 image Pi Zero is plugged into right hand USB port
For my install, I did the following: 1) Using Windows diskpart, I selected the SD card and then ran a 'clean' command to erase all partition data. 2) Put teslausb-buster-20190922 image on the card using Etcher. 3) Used the following config file details:
# Default variables for CIFS (Windows/Mac file sharing) setup
export ARCHIVE_SYSTEM=cifs
export archiveserver=192.168.0.100
export sharename=teslacam
export shareuser=teslacam
export sharepassword=password
export cifs_version="1.0"
# camsize of 14% gives 32GB image file size
export camsize=14%
# if you set camsize to less than 100%, but don't want music to use
# all the remaining space, you can specify how much space you want
# music to use by setting this variable
export musicsize=128G
# If you want to automatically copy music from a CIFS share every time
# the Pi connects to wifi, set the following variable. The share is
# assumed to exist on the same server as the archive share. It can
# be the same share as the share used for backing up recordings, but
# the folder needs to be different.
#export musicsharename=media/Music/Albums
# Wifi setup information. Note that Raspberry Pi Zero W only supports 2.4 GHz wifi
export SSID='MYWIFI'
export WIFIPASS='mywifipass'
# If doing a headless (i.e. automatic) setup
export HEADLESS_SETUP=true
# uncomment to enable a samba server that exports the recordings
#export SAMBA_ENABLED=true
# uncomment to enable guest access to the samba server
#export SAMBA_GUEST=true
# uncomment to enable teslausb to act as a wifi access point with the given
# SSID, so you can access it while on the road.
export AP_SSID='TESLAUSB WIFI'
# Change this! The setup script will not accept the default 'password'
# Also note that the wifi password must be at least 8 characters.
export AP_PASS='teslausbpass'
# IP address is optional. The AP will give its clients IP addresses in the
# x.x.x.100-150 range so make sure you don't put the AP's IP address in
# that range.
#export AP_IP='192.168.66.1'The resulting software was pulled from the main-dev branch.
Following the completion of the headless setup, I also ran: sudo -i /root/bin/remountfs_rw /root/bin/setup-teslausb selfupdate /root/bin/setup-teslausb reboot
This appears to be unneccessary, as no new packages were pulled down.
One thing I'm wondering is if the Pi could be thermal throttling. I have a heatsink on my CPU, which might be why I'm not seeing any issues. Monitoring temperatures and CPU clock speed might be an idea for those people who are seeing issues. From what I can see, the Pi Zero is slightly borderline in terms of speed when it comes to emulating USB storage. Any CPU speed reduction might well drop performance below the threshold that the car requires.
Some possible commands to try would be:
root@teslausb:~# vcgencmd measure_clock arm && vcgencmd measure_temp && vcgencmd get_throttled
frequency(45)=700000000
temp=39.5'C
throttled=0x0
root@teslausb:~# vcgencmd measure_clock arm && vcgencmd measure_temp && vcgencmd get_throttled
frequency(45)=1000000000
temp=40.6'C
throttled=0x0or possibly something like this:
while true; do echo `date` && vcgencmd measure_temp && vcgencmd measure_clock arm && vcgencmd measure_clock core; vcgencmd get_throttled; sleep 10; done >> /var/tmp/throttled.logMy clock frequency seems to cycle between 700MHz and 1GHz, dependent on CPU load. For reference, 'throttled' can take the following values:
What: /sys/devices/platform/soc/soc:firmware/get_throttled
Description: This file returns the firmware get_throttled value which is
divided into 2 parts:
- lower 16-bits are the live value
- upper 16-bits are the history or sticky value
Bits:
0: under-voltage
1: arm frequency capped
2: currently throttled
16: under-voltage has occurred
17: arm frequency capped has occurred
18: throttling has occurred
This file can be polled for changes.
What: /sys/devices/platform/soc/soc:firmware/get_throttled_mask
Description: This file does two things:
1. Describes which bits should denote a change when polling
2. The upper part is used when clearing the sticky bits
Default value is 1 << 16.
What: /sys/devices/platform/soc/soc:firmware/get_throttled_poll_ms
Description: Specifies the get_throttled polling interval in milliseconds
(default 2000ms). The kernel polls this value to detect
under-voltage and to support polling the get_throttled file for
changes. Setting this to zero disables polling.
marcone
andrewgarfield
vita10gy
miles267
japhule
acraigl
c-E-c-777
th3fallen
sottile
jbienz
From early view of release notes it looks like Tesla is changing/adding a folder to store Sentry Mode clips:
“Sentry Mode video clips are now saved in a separate folder on your USB drive to make them easier to review and manage. Also, the older Sentry mode video clips will now be automatically deleted if there is not enough space on the USB drive and Sentry Mode clips are using more than 5 Gigabytes of space.”
Not sure this impacts teslausb code or not.