They are added on pi1 now. They can be pushed up here.

640x480 is not an option for outdoor use at any distance. The image has no detail and cannot be used for any precision operations.

That eliminates mjpg use from the amcrest as all the support is 640x480 unless using rtsp.

Have to increase banwidth and reconnects to make rtsp as realtime as possible.

Or look at other cameras which support higher resolution mjpg. That is least preferrable option.

Ability for touchscreen regions to update pan-tilt position

Install on top of case, easy to reach not easy to bump.

validate settings

• lease time
• authoritative
• subnet range

Randomly. Possibly related to screen sleep.

Could be that the input dev is not long readable, killing the loop in the py script.

Py script should handle bad reads and just try again.

Install script is missing steps to copy dhcpd configs over to /etc

Relying on the software present in the cameras to reconnect is problematic and relies on undefined behavior of the internal network components.

The Amcrest API exposes wireless configuration in

• 4.7.6 WLan
• 4.7.7 Scan Wlan devices

It would seem reasonable to have a process either on a pi or a proton that is scanning regularly (every second) for a target SSID and when it is available a rest call can be made to the Amcrest API to initiate a connection.

The ENC28J60 is 10Mbps.

Will 10Mb connection run 2-3 cams at quality?

For now going to use a for loop in crontab to execute a cam reconnect.

Sync issues are reliably fixed by doing a killall. Add a hardware button until issue is identified.

Cron and the omx timeout need to be sane together.

Would give way more control and not using the cloud dashboard anyways.

https://wiki.openwrt.org/toh/openmesh/om2p
https://help.cloudtrax.com/hc/en-us/articles/202487954-Open-Mesh-and-OpenWRT
https://help.cloudtrax.com/hc/en-us/articles/202382890-Open-Mesh-development-information

Having predictable network interface names appears to prevent easy configuration sharing.

Disable it: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Tested this and is working, need to work into init scripts

Does laying a wifi antenna down horizontally alter the approach angle that reconnects are successful at?

Cams will need to recover when signal is lost, a wait-on will be simplest way to accomplish this initially.

Sending gps with electron

https://docs.particle.io/reference/firmware/photon/#tcpclient
https://docs.particle.io/reference/firmware/photon/#serial

rocks, wetspots, etc

When a keyboard is connected the touchscreen will be different input dev. Should be able to lock touch to a constant dev entry.

If not, going to need a ticket for a zero for dhcp for mesh device.

Terminal will be without interface devices (initially). Need to set views on boot, without login.

Was getting an error about "File 0 not found".

Fell back to the dualcam script.

Any difference in

• performance
• stability
• reconnect time

Better performance and longevity if SD is only used for boot.

Also will allow software updates to be made by swapping out drive vs. disassembling the device.

Need logging to review issues with

• reconnect attempts
• cam view attempts
• dhcp leases

Need profile based eth0 definitions that are copied on install.

The hypriot flasher is supposed to be installing this, has not been for a while.

flash -n mvf-2 --ssid 'my-ssid' -p my-psk -d /dev/mmcblk0 /usr/local/src/pi/2017-08-16-raspbian-stretch-lite.zip

Device will depend on PiJack status

What configuration gets pijack running on pi 2?

Doesnt seem to work out of the box as the site suggests.

Been doing this manually through raspi-config, needs scripted.

https://github.com/androidthings/drivers-samples/blob/master/gps/src/main/java/com/example/androidthings/driversamples/GpsActivity.java

Appears to be an issue where cameras cannot reconnect after some scenario where an amount of time passes. This could be related to default lease time on dhcp, or some other issue.

Significant problem as neither cron nor a wait_on curl will matter if the cam never reconnects.

See #16

PiJack didnt work out thus far, using the pi's eth0.

Need to update eth0 with static ip and disable eth1.

Wifi or bluetooth based relay support

Touch script does not seem to start. Is it a pip issue?

https://github.com/sstephenson/bats

Will get a bunch of SysRq : HELP : loglevel(0-9) on startup if UART is not disabled.

Edit /boot/cmdline.txt, removing the default tty console=ttyAMA0,115200 kgdboc=ttyAMA0,115200

Edit /etc/inittab remove spawning of ttyAMA0

Also console=serial0,115200 console=tty1

Reference

• https://raspberrypi.stackexchange.com/a/17012

notifications on entering or leaving

When a connection is not available the python script crashes.

For usability when using the machine

config.txt

lcd_rotate

https://www.raspberrypi.org/documentation/hardware/display/troubleshooting.md
https://www.raspberrypi.org/forums/viewtopic.php?f=108&t=120793

It has been noted multiple places that pi3 doesnt play well with adafruit gps.m

Ive also saw people say its possible.

Obviously would be good to upgrade to 3

Mount booster on back of cover and split the feed going to the router.

Need a larger supply, ~4 amp minimum.

Barrel on the booster is a 2.5mm OD

Unable to drop below .5 second latency with h.264 streams (average around .8). Which seems to be a limitation due to the frame diffing implementation of h.264. From what I understand some amount of buffer is not going to go away, and the more reduced the buffer the less smooth the stream. .5 seems to be the minimum, and is the lowest quality.

MJPEG on the other hand has higher bandwith requirements but initial testing is showing about a ~.2 latency. Though there is quality loss, this is a significant improvement.

Need to work this into the scripts. Would be nice to have parallel rtsp and mjpg capability to test against.

Sample settings are

omxplayer 'http://admin:password@cam1/cgi-bin/mjpg/video.cgi' \
  --win "400 0 800 480" \
  --live -r \
  --threshold .2 \
  --fps 30 \
  -n -1

https://github.com/jw3/mvf/blob/master/etc/dhcpd.conf.1#L16

should be dhcpd.mesh.1

• On: echo 0 > /sys/class/backlight/rpi_backlight/bl_power
• Off: echo 1 > /sys/class/backlight/rpi_backlight/bl_power

Currently flipping video 270° to support the vertical screen orientation (to maximize viewing efficiency).

Flipping it on the camera makes using the phone app or other methods of viewing awkward or useless.

Flip it with omxplayer with the --orientation flag.

--orientation n Set orientation of video (0, 90, 180 or 270)

https://github.com/popcornmix/omxplayer/blob/master/README.md

mesh1 mac is in mesh, ..

apt-get

• gpsd
• gpsd-clients
• python-gps

/boot/config.txt

• enable_uart=1