Revision history for MiniCarComputer
Revision [1994]
Last edited on 2013-12-27 18:22:29 by KarlMW [add some more power management ideas to consider]Additions:
====__More Power Management Notes__====
- connection to host
- minimum requirements:
- 1 signal to rPi to indicate current main power status (car running or off)
- 1 signal from rPi to request shutdown
- digital I/O is simple to connect to rPi
- USB would allow more flexibility to use this board for other things
- sensing of the world
- main power status input
- pref via R network with some voltage limiting so that it could be used for 12V or 5V or something else
- pref with schmitt input or such so that it has sharply defined threshold and does not get upset by slowly dropping voltage
- optional bridge rectifier for sensing AC?
- optocoupled input for sensing AC mains?
- optional analog sensing so as to measure input voltage?
- space for small C for transient suppression (or could do this in software)
further options:
- measure car 12V voltage as well as own battery voltage?
- extra signal to rPi to indicate impending SLA battery failure and shutdown
- domestic usage
- control a mains relay (or SSR/triac) so that we can use it for a domestic device
- pref optocoupled for safety
- could have 2 controlled outputs so that it can manage its own mains as well as another device?
- mains power loss sensing?
- optional timer in PSU controller to restore power after "x" time period
- eg. to use for a device which powers on and runs a scheduled backup of something every day
- connection to host
- minimum requirements:
- 1 signal to rPi to indicate current main power status (car running or off)
- 1 signal from rPi to request shutdown
- digital I/O is simple to connect to rPi
- USB would allow more flexibility to use this board for other things
- sensing of the world
- main power status input
- pref via R network with some voltage limiting so that it could be used for 12V or 5V or something else
- pref with schmitt input or such so that it has sharply defined threshold and does not get upset by slowly dropping voltage
- optional bridge rectifier for sensing AC?
- optocoupled input for sensing AC mains?
- optional analog sensing so as to measure input voltage?
- space for small C for transient suppression (or could do this in software)
further options:
- measure car 12V voltage as well as own battery voltage?
- extra signal to rPi to indicate impending SLA battery failure and shutdown
- domestic usage
- control a mains relay (or SSR/triac) so that we can use it for a domestic device
- pref optocoupled for safety
- could have 2 controlled outputs so that it can manage its own mains as well as another device?
- mains power loss sensing?
- optional timer in PSU controller to restore power after "x" time period
- eg. to use for a device which powers on and runs a scheduled backup of something every day
Additions:
- 2 streams for??? One high rate and one low rate???
====__Misc 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
====__Wifi Notes__====
- HostAP would be useful for phone to connect to, but ad-hoc wifi would be sufficient (needs rooted phone)
- potentially useful HostAP links
====__Power Management Notes__====
- 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
CategoryKMWDiscussions
====__Misc 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
====__Wifi Notes__====
- HostAP would be useful for phone to connect to, but ad-hoc wifi would be sufficient (needs rooted phone)
- potentially useful HostAP links
====__Power Management Notes__====
- 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
CategoryKMWDiscussions
Deletions:
- /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 a10Core setup notes__====
- /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
====__HostAP__====
- potentially useful links
Additions:
====__a10Core notes__====
- /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 a10Core setup notes__====
- logs:
- my logs: /var/log/usr
- boot log: /var/log/usr/boot*.log
- syslog: /var/log/messages
- /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
====__HostAP__====
- normal wifi kernel module used by mini-x is 8192cu
- potentially useful 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
- /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 a10Core setup notes__====
- logs:
- my logs: /var/log/usr
- boot log: /var/log/usr/boot*.log
- syslog: /var/log/messages
- /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
====__HostAP__====
- normal wifi kernel module used by mini-x is 8192cu
- potentially useful 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
Additions:
CategoryIdeas
Revision [1855]
Edited on 2013-05-04 21:58:44 by KarlMW [log crypto, accelerometers, fix some indents]Additions:
- probably less trouble to just use a tablet, assuming infrequent use
- 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
- GPG public key encryption
- public key is use to encrypt files
- private key (which is not on the device) is used to decrypt
- 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
- engine status (to allow orderly shutdown when engine stopped)
- 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
- GPG public key encryption
- public key is use to encrypt files
- private key (which is not on the device) is used to decrypt
- 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
- engine status (to allow orderly shutdown when engine stopped)
Deletions:
- 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
- engine status (to allow orderly shutdown when engine stopped)
Additions:
====__Ideas for use__====
- mpd server
- xbmc (local movie play for trips)
- video capture
- continual webcam snapshots to storage (EXIF tagged with GPS)
- live video storage (2 streams preferable)
- 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
- hostAP (access point for other in car devices)
====__Notes__====
- Encrypted storage for logs somehow
- 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
- 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?
- mpd server
- xbmc (local movie play for trips)
- video capture
- continual webcam snapshots to storage (EXIF tagged with GPS)
- live video storage (2 streams preferable)
- 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
- hostAP (access point for other in car devices)
====__Notes__====
- Encrypted storage for logs somehow
- 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
- 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?
Deletions:
mpd server
continual webcam snapshots to storage (EXIF tagged with GPS)
live video storage (2 streams preferable)
push button high res camera snapshot to storage
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)
xbmc (local movie play for trips)
hostAP (access point for other in car devices)
G meter/logger
====Notes====
Encrypted storage for logs somehow
Managed startup/shutdown with vehicle use
Possibility of keeping it running when not in vehicle (uploads via home wifi, or security functions e.g. geofencing, remote webcam monitoring for stalking)
Additions:
====Notes====
Deletions:
Additions:
====Ideas for use====
mpd server
continual webcam snapshots to storage (EXIF tagged with GPS)
live video storage (2 streams preferable)
push button high res camera snapshot to storage
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)
xbmc (local movie play for trips)
hostAP (access point for other in car devices)
G meter/logger
====Notes===
Encrypted storage for logs somehow
Managed startup/shutdown with vehicle use
Possibility of keeping it running when not in vehicle (uploads via home wifi, or security functions e.g. geofencing, remote webcam monitoring for stalking)
mpd server
continual webcam snapshots to storage (EXIF tagged with GPS)
live video storage (2 streams preferable)
push button high res camera snapshot to storage
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)
xbmc (local movie play for trips)
hostAP (access point for other in car devices)
G meter/logger
====Notes===
Encrypted storage for logs somehow
Managed startup/shutdown with vehicle use
Possibility of keeping it running when not in vehicle (uploads via home wifi, or security functions e.g. geofencing, remote webcam monitoring for stalking)