Comparing revisions for MiniCarComputer
- [1851] 2013-05-03 14:07:04 by ZorrUno (unregistered user) [started]
- [1870] 2013-05-25 16:03:51 by KarlMW (unregistered user) [mostly power management notes]
Deletions:
- mpd server
- xbmc (local movie play for trips)
- probably less trouble to just use a tablet, assuming infrequent use
- video capture
- continual webcam snapshots to storage (EXIF tagged with GPS)
- live video storage (2 streams preferable)
- 2 streams for??? One high rate and one low rate???
- push button high res camera snapshot to storage
- data logging
- GPS logs
- upload automatically via Wifi when in range of known AP
- some uploads continually via 3G (vodem or wifi repeat i.e. portable vodafone AP)
- G meter/logger (accelerometer)
- eg. 3-axis accelerometer NZD$39
- http://www.mindkits.co.nz/store/sensors/movement-and-position/triple-axis-accelerometer-breakout-adxl335
- eg. 9DOF IMU NZD$179
- http://www.mindkits.co.nz/store/sensors/movement-and-position/9-degrees-of-freedom-razor-imu-ahrs-compatible-2
- hostAP (access point for other in car devices)
====__Misc Notes__====
- Encrypted storage for logs somehow
- GPG public key encryption
- public key is use to encrypt files
- private key (which is not on the device) is used to decrypt
- could use teensy for I/O
- IR rx for user interface via a remote
- accelerometer
- car info? (misc car logging? temperature?)
- LCD display?
- engine status (to allow orderly shutdown when engine stopped)
- probably need a powered hub to supply GPS and to get enough ports
- USB ports required somewhere:
- GPS
- music flashdrive (or HDD)
- keypad?
- spoken audio announcements of stuff?
====__a10Core notes__====
- boot scripts:
- standard TinyCore scripts:
- /opt/bootsync.sh is executed first, before console prompt appears
- this is the place to put anything that tweaks the user home
- /opt/bootlocal.sh is executed after console prompt appears
- this iterates over /opt/bootlocal.d
- KMW additions - /opt/bootlocal.d:
- scripts are executed in lexical order
- they need to be executable, as per normal...
- filenames are constrained to alphanum/underscore/dash
- filenames containing dots are ignored!
- usual way to disable a script is to rename it something.DISABLED
- logs:
- syslog: /var/log/messages
- my logs: /var/log/usr
- boot log: /var/log/usr/boot*.log
====__Wifi Notes__====
- normal wifi kernel module used by mini-x is 8192cu
- HostAP would be useful for phone to connect to, but ad-hoc wifi would be sufficient (needs rooted phone)
- potentially useful HostAP links
- http://acx100.erley.org/acx/nl80211_master_mode.html
- http://rtl8192cu.googlecode.com/hg-history/bdd3a2265bdd6a92f24cef3d52fa594b2844c9c1/document/Quick_Start_Guide_for_SoftAP.pdf
- http://nims11.wordpress.com/2012/04/27/hostapd-the-linux-way-to-create-virtual-wifi-access-point/
- http://wireless.kernel.org/en/users/Documentation/hostapd
- http://blog.sip2serve.com/post/38010690418/raspberry-pi-access-point-using-rtl8192cu
- http://home.comcast.net/~tomhorsley/hardware/rtl8192cu/rtl8192cu.html
- http://raspberrypi.stackexchange.com/questions/5593/how-to-use-a-wifi-dongle-on-raspbian-to-transform-the-pi-into-an-access-point
====__Power Management Notes__====
- power management
- Managed startup/shutdown with vehicle use
- Possibility of keeping it running when not in vehicle
- uploads via home wifi
- security functions e.g. geofencing, remote webcam monitoring for stalking
- simplest option is perhaps to have it powered by a 7Ahr battery which is continuously charged when car is running
- careful not to suck power from car battery when engine is not running
- computer needs awareness of current power source so it can initiate orderly shutdown when engine is turned off
- may need some handling for instances where power is lost briefly or car restarts just after mini-x shuts down
- just before mini-x starts shutdown sequence, assert a signal to power management which indicates that power should be restored *after* it is cut, if car power resumes
- possible power controller approaches
- minimum requirement:
- I/O:
- car power status signal to mini-x so it knows that power is about to die
- functionality:
- sustain power for 10s (or some other time) after car is turned off
- enough time to close logs cleanly and shutdown mini-x
- mini-x has no control and therefore has no risk of draining car battery
- better approach (could be achieved with a couple of relays and no real smarts):
- I/O:
- signal to mini-x so it knows that power is about to die
- signal from mini-x to shutdown power
- functionality:
- sustain power to mini-x until signal from mini-x says to shut down
- risk of draining car battery if mini-x loses its marbles
- even better approach:
- I/O:
- signal to mini-x so it knows that power is about to die
- signal from mini-x to shutdown power
- functionality:
- sustain power to mini-x until signal from mini-x says to shut down
- limit max duration of power sustaining (eg. to 15min)
- time limit ensures that mini-x can never exhaust car battery
CategoryIdeas
CategoryKMWDiscussions