Changes

805 bytes added ,  20:25, 18 January 2011
m
no edit summary
Line 51: Line 51:       −
On starting the GoGo activity the Console-Tab is displayed as shown below. In the top of the central region is the name and version of the activity. Please quote the version number if you encounter any problems (on SugarLabs Bugs site [4]). In the center is the image of the GoGo-Board itself, which will be larger is the next version. Below that is the current status "GoGo Connected"/"GoGo Disconnected" followed by "Connect"/"Disconnect" buttons. Also note the status-bar at the bottom of the screen which displays (sometimes transient) messages.
+
On starting the GoGo activity the Console-Tab is displayed as shown below. In the top of the central region is the name and version of the activity. Please quote the version number if you encounter any problems ([[Activity/Gogo#Suggestions and Bug Reports|Suggestions & Bug Reports]]). In the center is the image of the GoGo-Board itself, which will be larger is the next version. Below that is the current status "GoGo Connected"/"GoGo Disconnected" followed by "Connect"/"Disconnect" buttons. Also note the status-bar at the bottom of the screen which displays (sometimes transient) messages.
      Line 84: Line 84:       −
The GoGo-Board can store compiled Logo code which can be run by clicking the board's "run" button. Stored code can be run with/ without the board being connected to the XO (batteries or alternative power source are required when the board is untethered). Code is created, edited, saved, loaded and "uploaded" via the Logo Procedures tab shown in the image below. Code is compiled and uploaded (if no errors) in a single step when the "Upload" button is clicked. The "Messages" section will report any errors in the Logo code, in which case nothing should actually be uploaded to the board.
+
The GoGo-Board can store compiled Logo code which can be run by clicking the board's "run" button. Stored code can be run with/ without the board being connected to the XO (batteries or alternative power source are required when the board is untethered). Code is created, edited, saved, loaded and "downloaded" via the Logo Procedures tab shown in the image below. Code is compiled and uploaded (if no errors) in a single step when the "Download" button is clicked. The "Messages" section will report any errors in the Logo code, in which case nothing will actually be downloaded to the board.
      Line 91: Line 91:  
  [[File:gg-logo.png]]
 
  [[File:gg-logo.png]]
 
</center>
 
</center>
      
===Data Upload Tab: Capture, Graph & Save===
 
===Data Upload Tab: Capture, Graph & Save===
      −
Logo procedures can include commands to capture data, storing it on-board until uploaded to the XO. This can be done on the "Data Upload" tab (shown below) by clicking on the "Start" button (top left). The adjacent progress-bar and upload-count will update as data is uploaded. The data will be displayed in the "Recorded Data" section after the upload completes. Data can be displayed in Table or Graph format. In Table format the data can be formatted across a number of columns, which is required when data from more than one sensor/ source is interleaved. A sensor "type" can be selected to display the name & units and to apply calibration to for each column (see next section for how this information is created). Sensor Names & Units are used to display column headers. Name and Unit can be on the same line ("Name (Units)") or split on their own line (a two-line header). Data can be saved in Comma-Separated-Variables (CSV) format along with one/two headers (if selected).
+
Logo procedures can include commands to capture data and store it on-board until uploaded to the XO. This can be done on the "Data Upload" tab (shown below) by clicking on the "Start" button (top left). The adjacent progress-bar and upload-count will update as data is uploaded. The data will be displayed in the "Recorded Data" section after the upload completes. Data can be displayed in Table or Graph format. In Table format the data can be formatted across a number of columns, which is required when data from more than one sensor/ source is interleaved. A sensor "type" can be selected to display the name & units and to apply calibration to each column (see next section for how this information is created). Sensor Names & Units are used to display column headers. Name and Unit can be on the same line ("Name (Units)") or split on their own line (a two-line header). Data can be saved in Comma-Separated-Variables (CSV) format along with one/two lines of header (if "Headers" check-box is selected).
      Line 112: Line 111:  
  [[File:gg-upload-2.png]]
 
  [[File:gg-upload-2.png]]
 
</center>
 
</center>
 +
      Line 117: Line 117:       −
Sensor values, even for switches, fall in the range 0..1023. The Sensor-Lab is where particular sensor "types" can be created to calibrate these values, give more meaningful names and specify the units used (eg, Resistance, KOhms). Calibration data is defined by specifying a number of calibration "points" between which the application will interpolate to convert the raw sensor values. In this way a library can be created of commonly encountered sensor types and their calibration data can be assigned when monitoring sensors in the Console tab and when importing captured data in the "Data Upload" tab. In the image below you can see the list of sensors, the calibration points for the selected sensor and a (slightly rough) idea of the shape of the calibration curve in the graph. For easier creation and editing of calibration data the information for each sensor can be exported and imported in both Comma-Separated-Variables (CSV) format or custom "Sensor" format. Like-wise sensor information can imported in either of these formats.   
+
Sensor values, even for switches, fall in the range 0..1023. The Sensor-Lab is where particular sensor "types" can be created to calibrate these values, give more meaningful names and specify the units used (eg, Resistance, KOhms). Calibration data is defined by specifying a number of calibration "points" between which the application will interpolate to convert the raw sensor values. In this way a library can be created of commonly encountered sensor types and their calibration data can be assigned when monitoring sensors in the Console tab and when importing captured data in the "Data Upload" tab. In the image below you can see the list of sensors, the calibration points for the selected sensor and a (slightly rough) idea of the shape of the calibration curve in the graph. For easier creation and editing of calibration data the information for each sensor can be exported and imported in both Comma-Separated-Variables (CSV) format or a custom "Sensor" format.  
      Line 159: Line 159:       −
...yep, user "olpc" is a member of "dialout". So in the above example all is well. If your results differ from these then please post a bug at SugarLabs Bug website [4]. Note that some older XO/OS's use different device files and/or groups and it may need root access to fix any problem.
+
...yep, user "olpc" is a member of "dialout". So in the above example all is well. If your results differ from these then please post a bug ([[Activity/Gogo#Suggestions and Bug Reports|Suggestions & Bug Reports]]). Note that some older XO/OS's use different device files and/or groups and it may need root access to fix any problem.
      Line 165: Line 165:  
==Upcoming Changes==
 
==Upcoming Changes==
   −
TBD
+
 
 +
Improving existing features is an ongoing effort. These are new feature are currently being worked on:
 +
 
 +
 
 +
* Logo commands reference on-screen
 +
 
 +
* Logo line numbering
 +
 
 +
* Logo syntax highlighting
 +
 
 +
* Strip-chart for sensor monitoring
 +
 
 +
 
      Line 172: Line 184:       −
The GoGo Activity is an open-source project and contributions in terms of code, graphics, testing and feedback are welcome. Bug reports should be submitted on SugarLab's Bug site [4]. Code and graphics should be contributed via the GIT repository [5]. Language translations should be via SugarLab's Pootle port-hole [6].  
+
The GoGo Activity is an open-source project and contributions in terms of code, graphics, testing and feedback are welcome. Bug reports should be submitted on SugarLab's Bug site ([[Activity/Gogo#Suggestions and Bug Reports|Suggestions & Bug Reports]]). Code and graphics should be contributed via the GIT repository [5]. Language translations should be via SugarLab's Pootle port-hole [6].  
 +
 
 +
Please also remember that the GoGo Activity is originally based on Br-GoGo [2] and the intention is to eventually contribute back to that project so please also consider contributing to that project.
 +
 
 +
 
 +
 
 +
==Suggestions and Bug Reports==
 +
 
 +
 
 +
When reporting bugs please provide as much information as possible including version numbers for XO hardware, OS and Sugar.
 +
 
 +
 
 +
* [https://bugs.sugarlabs.org/newticket?component=GoGo Click here to submit suggestions or report a GoGo bug]
 +
 
 +
* [https://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&component=GoGo Click here to view current GoGo suggestions & bugs]
   −
Please also remember GoGo is originally based on Br-GoGo [2] and the intention is to eventually contribute back to that project so please also consider contributing to that project.
       
35

edits