_       
| \    /\
|  \  / /
|  (_/ / 
|   _ (  
|  ( \ \ 
|  /  \ \
|_/    \/
         

         
         
  ####   
 ##  ##  
 ######  
 ##      
  ####   
         

         
##  # ## 
##  #  # 
 ## ## # 
 ### ##  
  ## ##  
  #   #  
         

 _______ 
(  ____ \
| (    \/
| (__    
|  __)   
| (      
| )      
|/       
         

         
  ###    
   ##    
   ##    
   ##    
   ##    
  ####   
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''Use of the Genboard to log not only engine parameters, but function as a collection point for all car/ race car data''' This WIKI page came from the needs of MembersPage/RedMist and MembersPage/RichardBarrington to integrate all critical race car parameters into one serial stream for logging / out of bounds alerts on a PDA. It was decided early on in the project that others may benefit from inclusion, and this was best to remain a collaborative effort of the VEMS team. '''AIM ''' To produce an easily adaptable and affordable datalogger for logging all mission critical data in a race vehicle. This is to be kept as generic as possible so that any effort may be applied to the collaborative Genboard project and be easily adapted to the needs of the group. '''Constraints''' In order for this project to become a collaborative effort success it must cater to as much of the existing group’s needs. As such I think it wise to keep as much of the standard Genboard functionality as possible, leverage off that code and develop an extension to the existing functions. This would also allow for the possibility of an extension to the project team or allow for maintenance or further development to be introduced back into the VEMS fold. As such I propose that all the standard pinouts for Genboard be retained and additional channels be used where applicable for any additional requirements. Hall sensor input would be limited to a single channel as the other would be required by CAM angle sensor. However for those with datalogging only requirements both must be able to be used for wheel speed disparity, traction control, etc. Recent discussions on IRC suggest that there may be a possibility of adding a FV converter to the board in order to allow this function without taking up hall channels. In order to keep the extension to the code simplistic and minimal I propose that the Genboard only be used for signal conditioning and processing of data so that it may be presented to an external data processor (PDA). Coding on said device would be easier and more open to feature addition without the necessity to worry about features tying up valuable processor cycles when needed to fire injectors or coils. It would also minimise the prospect of mission critical engine functions failing due to a coding error with the datalogging code. This should be investigated further. If the numbercrunching (which kindof compresses data) happens offboard GenBoard, we might seriously limit what/how much can be logged to MMC. It would be nice if the user could select where he'd like the evaluation to take place. '''Required Inputs''' Please note that every input has first been given a requirement statement to ensure that the function is not developed as a toy. Suspension position. Essential to enable the correct tuning of shock absorbers or metering of how rough a course is. * GenBoard/LoggerIntegration/DedicatedLogger/Suspension Steering angle. Necessary to meter slip angles, suspension change effectiveness, and possibly may be used as an input into traction control. * GenBoard/LoggerIntegration/DedicatedLogger/Steering Wheel Speed, necessary to meter top speed, wheel slip, may be used as an input into traction control * GenBoard/LoggerIntegration/DedicatedLogger/WheelSpeed Measurement of G-Forces. Required for virtual dyno, measurement of how rough a course is, suspension change effectiveness, cornering effectiveness, tyre performance. * GenBoard/LoggerIntegration/DedicatedLogger/Gforce A warning off switch. Specific requirement of the PDA system. With the Bunderson, and I suspect many other vehicles the PDA will be sealed and button function will not be accessible. If the PDA is programmed to supply out of bounds alerts the alerts must be able to be switched off given a toggle switch position. Unfortunately this button cannot be directly accessed by the PDA itself, however insertion of a toggle switch position in the Genboard serial stream would allow the audio warnings to be toggled off. * GenBoard/LoggerIntegration/DedicatedLogger/WarningOff Tag Switch. Used to tag the datalog with unusual events. Possibly the start of a race, stuttering, or perhaps environmental issues (bloody big jump). * GenBoard/LoggerIntegration/DedicatedLogger/TagSwitch Measurement of brake pressure or pedal movement. Requirement for metering the driver or the effectiveness of brakes during racing. * GenBoard/LoggerIntegration/DedicatedLogger/Brake Lap timing trigger. Gives the driver the ability to meter his own effectiveness or meter the performance of the car given changes. * GenBoard/LoggerIntegration/DedicatedLogger/LapTime Engine Parameters. Allow virtual dyno to work, will give indication of mechanical or electrical failure. * GenBoard/LoggerIntegration/DedicatedLogger/Engine '''Output''' At present the planned output is a simple serial stream. No standard ECU functions will be used, however no existing ECU pins are to be used by the datalogger function. * GenBoard/LoggerIntegration/DedicatedLogger/Output '''Coding Changes Necessary''' * GenBoard/LoggerIntegration/DedicatedLogger/Coding '''PDA as a datalogging and out of bounds alert device''' There is currently no intention to use a PDA as a tuning device, as MembersPage/RedMist believes that a laptop or the currently being developed GBA code should suffice. However there is every intention to use the cheap, solid state memory and interface of the PDA to log every race car critical parameter. In addition display and audio out of bounds alerts will certainly add to functionality. The communication should be the new generalized format as on GenBoard/BinaryProtocol (same for MMC/PDA logging, tuning and between computers on-deck). A binary protocol with checksum is the best possible utilization of the available serial bandwidth: * different packets can be used in the same stream, so not all data is sent with the same frequency (eg. WBO2 measurement can be sent more frequently than, say VBATT or board version) * with the checksum, you can be sure about packet integrity. Nothing sucks as much as debugging problems that arise from random data corruption. Without the checksum there is not a single sample you can be confident of. Even without the checksum there is still information in the stream statistically, of course, but significantly less than with checksum, assuming the same raw bandwidth. * No (absolute) need for an ACK packet (but possible, of course). Actually, when storing the packets in MMC there is nothing to send back any ACK packet * A Timestamp at the front of the packet is a necessity and also allows for some interpolation between the lines surrounding the lost data. Considering we'll be attempting to dump as many lines of data as possible as little overhead as practicable is requied. * GenBoard/LoggerIntegration/DedicatedLogger/PDA * GenBoard/LoggerIntegration/DedicatedLogger/VirtualDyno
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.