View source

Our loggers gather data from the sensors and store them in the local database.

They are each assigned a status indicator on the control panel which they update when status

of their data source changes. 


 note that much of what is on this page was written for the first prototype in 2004.

Each should also provide a trivial way for other processes on the bike to get at the latest records.



=== Logging WIFI Availability: ===

We will log all detected wireless networks, together with the current position, signal strength and results of our attempts to get online trough them. We will also log loss-of-signal events.

Besides the environment variables set by the waproamd, we will look at what the card reports in <nowiki>file:///proc/net/wireless</nowiki>



An existing wifi survey software of high quality is kismet. We might want to use it if we are interested in mapping the closed links and access points. Perhaps simply switching between them every 5 minutes would be something. 



=== Logging location: ===

Our gpsd client parses the information into mostly numerical pieces.

There are three interleaving streams of data - the waypoints, the satellite reception statistics and proprietary magellan info, where only battery status seems nonredundant. 

Looks like we should take care not to record consecutive identical positions, as they

are just old values reported because of a temporary loss of satellite signal. 



It seems practical to use the WGS84 coordinate system for all but the final screen display. So we do. The gps receiver can be configured with other systems, so this setting should be checked from time to time.



The SQL schema for the GPS data we get looks like this:



 <nowiki>

create user frida;

create database frida owner frida;

\c frida frida;





BEGIN;



CREATE SEQUENCE frida_gps_seq;



CREATE TABLE waypoint (

  id integer default nextval('frida_gps_seq') primary key,

  ctime timestamptz default now(),



  lat numeric, -- decimal degrees

  long numeric, -- decimal degrees

  alt numeric, -- meters

  track numeric, -- meters?

  speed numeric, -- km/h? m/s?



  fixtime timestamptz, -- this we get from the GPS in UTC. send to db as YYYY-MM-DD HH:MM:SS+00



  status int, -- 1-fix, 2-dgps fix

  mode int, -- 2-2d fix, 3-3d fix

  quality int, -- why is this always 12?

  pdop numeric, -- dop seems to work

  hdop numeric, 

  vdop numeric,

  satstat integer -- references satstat(id)

);



CREATE TABLE satstat (

  id integer default nextval('frida_gps_seq') primary key,

  ctime timestamptz default now(),

  used integer

);



CREATE TABLE satellite (

  satstat integer not null,

  prn integer,

  elev integer,

  azim integer,

  snr integer,

  used bool



);



ALTER TABLE satellite ADD PRIMARY KEY (satstat, prn);



CREATE TABLE magellan (

  id integer default nextval('frida_gps_seq'),

  ctime timestamptz default now(),

  battery numeric

);



COMMIT;

ROLLBACK;





</nowiki>



=== Logging multimedia ===



The media logger will capture movies, still images and sounds from the bicycle-mounted camera

and microphone. The files will be time- and geo-referenced and include the keyword icon set at

the control panel at recording time.



=== Logging user interaction ===



This simple logger will record all keypresses and switch changes detected on the control panel. 

Not meant as a big brother measure, rather as usability testing data.



=== Saving juice ===

one idea for conserving power in this process is a 10 minute tick time. 

every 10 minutes on the minute, all loggers create their output, wait random(10) and write the output.

normally the loggers produce output as soon as they get the required input. after that for 10 minutes

they all just buffer in RAM, allowing the hard disk to spin down. before doing it this way, 

memory requirements need to be checked. also the expected benefit needs to be estimated.