Sunday 28 June 2015

(Vacation) WEEK TEN: 22 June to 28 June 2015

Task 1: CANBUS - Ethernet Testing

The Ethernet Shield was tested in order to verify that communication can be done in the CAN bus system.

We tested the Ethernet shield to check if we can connect the Arduino to a specific IP address. Therefore, when we key the IP address of the Arduino code into our web browser, we would be able to see the readings for the analog pins.

The IP address would be of a similar range to the IP address of the router that we are using. The figure below would show the results that we have obtained from testing the Ethernet Shield

Figure 1. Ethernet Shield Testing Results


Task 2: Logging GPS Coordinates

This week, we managed to get the GPS module EM406 talking to the satellite. Testing was done at various locations to ensure that the GPS coordinates are accurate. The accuracy of GPS module depends on the location that we are at. It was difficult to obtain accurate coordinates indoors as the satellite was not communicating well with EM406. Thus, It would show an "INVALID" on our serial port as shown below. 

Figure 2. GPS Tracking Program and Serial Output
We were able to obtain the accurate readings once we are in open air and the module is communicating with the satellite. When moving, the coordinates also changes. The date and time logged by the GPS module is GMT timing. This means that during the actual race, we would have to convert the time to Australia timing. 

In order to get the GPS program to run, the tinyGPS++ library have to be installed. Appendix is our program for testing the module. 

#include <TinyGPS++.h> //include this library for the GPS to work
#include <SoftwareSerial.h> //this is the GPS software serial library

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 2;
int TXPin = 3;

// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
  // Start the Arduino hardware serial port at 9600 baud
  Serial.begin(9600);

  // Start the software serial port at the GPS's default baud
  gpsSerial.begin(GPSBaud);

  Serial.println(F("DeviceExample.ino"));
  Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
  Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
  Serial.println(F("by Mikal Hart"));
  Serial.println();
}

void loop()
{
  // This sketch displays information every time a new sentence is correctly encoded.
  while (gpsSerial.available() > 0)
    if (gps.encode(gpsSerial.read()))
      displayInfo();

  // If 5000 milliseconds pass and there are no characters coming in
  // over the software serial port, show a "No GPS detected" error
  if (millis() > 5000 && gps.charsProcessed() < 10)
  {
    Serial.println(F("No GPS detected"));
    while(true);
  }
}

void displayInfo()
{
  Serial.print(F("Location: ")); 
  if (gps.location.isValid())
  {
    Serial.print(gps.location.lat(), 6);
    Serial.print(F(","));
    Serial.print(gps.location.lng(), 6);
  }
  else
  {
    Serial.print(F("INVALID"));
  }

  Serial.print(F("  Date/Time: "));
  if (gps.date.isValid())
  {
    Serial.print(gps.date.month());
    Serial.print(F("/"));
    Serial.print(gps.date.day());
    Serial.print(F("/"));
    Serial.print(gps.date.year());
  }
  else
  {
    Serial.print(F("INVALID"));
  }

  Serial.print(F(" "));
  if (gps.time.isValid())
  {
    if (gps.time.hour() < 10) Serial.print(F("0"));
    Serial.print(gps.time.hour());
    Serial.print(F(":"));
    if (gps.time.minute() < 10) Serial.print(F("0"));
    Serial.print(gps.time.minute());
    Serial.print(F(":"));
    if (gps.time.second() < 10) Serial.print(F("0"));
    Serial.print(gps.time.second());
    Serial.print(F("."));
    if (gps.time.centisecond() < 10) Serial.print(F("0"));
    Serial.print(gps.time.centisecond());
  }
  else
  {
    Serial.print(F("INVALID"));
  }

  Serial.println();
}

We hope to get GPS coordinates and have it displayed on DAQ so that we can save the file for analysis. 

Monday 22 June 2015

(Vacation) WEEK NINE: 15 Jun to 21 Jun 2015

Task 1: Voltage Signal Attenuation

When looking back at the voltage measurement for the battery, we realise that there is much to be improved with the circuit that we came up with so far. Therefore, we looked into ways of improving the circuit of the voltage measurement, while improving the accuracy of our measurements.

Thus, we have looked into one of the suggestions given by our lecturers, to use a current sensor and a resistor to be connected in parallel with the SunSPEC 4's motor. This would thus omit the danger for shorting the high voltage and low voltage sides, while allowing us to implement circuits that boosts the sensor's sensitivity.

Figure 1 would show the circuit diagram. Note that the circuit does not include the solar panels as a power source, as we want to show the measurement of the battery voltage.

Figure 1. Voltage Sensing Circuit Diagram



Task 2: Current Amplifier

After connecting the current sensor and resistor in parallel with the car's motor, we are implementing a circuit that boosts the current sensor's sensitivity. In Figure 2 below, the V1 is referring to the current sensor's output.

Figure 2. Current Amplifier Circuit Diagram
Task 3: Current Calibration

The current sensor that we got is a hall-effect sensor. We tested it out to obtain the sensitivity and accuracy of the sensor. The power supply can supply 0 - 3.25 ampers. Thus, we experimented and obtain readings for every 0.1A. 

Figure 3. Set up of current calibration
Figure 4. Voltage - Current Graph
From our experiment, we noticed a change of 0.01V for every 0.1A change. The sensitivity of the sensor is roughly 100mV/A, which is much higher than our initial current sensor. However, the loop is very small and fits up to AWG12 only. We still have to look into other sensors as motor and battery side requires AWG8.







Saturday 13 June 2015

(Vacation) WEEK EIGHT: 8 Jun to 14 Jun 2015

Task: GPS Tracking of Solar Car

In 2013, the GPS module was placed on SunSPEC3 for the GPS coordinates. By placing the GPS module on the solar car itself, a more accurate terrain can be plotted.

Figure 1. Plotting altitude against distance
The above figure is the terrain obtained by the SunSPEC 3 team after the race. GPS tracking allows us to know the conditions of the route. With reference to the route profile, the telemetry team is able to strategize for the car to perform optimally.

As we will be using Arduino for programming, GPS module and GPS shield must be arduino-compatible. In this case, we looked into the GPS Receiver Module (EM-506).
Figure 2. GPS Receiver EM-506 Module
This receiver module has 48 frequency channels to choose from. It has extremely high sensitivity. Current drawn is small which is favourable as we have limited power from solar panels and batteries.

With the help of an Arduino GPS Shield and data logging shield. The GPS coordinates can be transmitted to computer and data can be saved for analysis. 

Figure 3. Arduino UNO with GPS Shield and EM-506

Programming of GPS tracking is rather easy with tutorials in the arduino library. Here's an exampe of the GPS program: 
Figure 4. Schematic of GPS tracking with Display
How to use the GPS Shield?

In order to operate the GPS, some settings must be done on the GPS Shield itself. 

There are two switches, one of  it is the power switch to turn on and off the GPS. The other one is the UART / DLINE switch, which controls how the Arduino communicates with the GPS Module. 

When set to UART mode, it will configure the board to use the hardware serial, which is the built-in Arduino hardware serial. It uses pin 1 and 2 for transmitting and receiving, communicating with the satellite. 

When set to DLINE mode, the board will be configured to use the software serial. The software serial library must be included in the code for the program to run. By default, pin 2 and 3 will be used for transmitting and receiving. 

In order to upload a program to the Arduino with GPS shield attached, switch must be set to DLINE mode.

Sunday 7 June 2015

WEEK SIX/SEVEN: 25 May to 7 Jun 2015

Task 1: CAN Bus
Figure 1. CAN Bus Shield, Arduino compatible
Our team tried to program the CAN Bus shield this week with a simple program found in the arduino library. CAN Bus is important as it allows us to communicate with parts of the system such as the battery management system. At the same time, CAN Bus shield also has the ability to log data, which enables us to so that we could allow the arduino to be CAN Bus compatible and the ability to communicate and log data from the rest of the system. The CAN Bus shield can just be placed above the arduino for compatibility use. This CAN Bus shield has a RS232 input socket which will allow it to transmit data using a cable. It also has a memory card slot which will allow it to log data accurately. Due to the fact that the data transmitted is by wireless, there is a possibility that data may be lost along the way. The memory stick can be used as a backup as well as cross checking the data recorded by the chase vehicle.




Task 2: RF Modem


Figure 2 (a). XStream Modem 
Figure 2(b). Xbee Modem

RF Modem is used for wireless transmission of data from the solar vehicle to our chase vehicle. Modems used come from Xbee(Fig 2)  and Xtreme(Fig 1). When doing past technical testing, the Xtreme performs more reliably than the Xbee. The Xtreme covers a further range compared to the Xbee modem, although Xbee is stated to have a further range than the Xtream modem. Thus,in 2013, the Sunspec 3 uses the Xtreme modem. Like wise, for 2015, we will be using Xtreme for Sunspec 4.

Configuration of the xstream modem is via the software X-CTU. It can be installed with a disk that comes with xstream modem, while having the modem plugged into your computer. This is the first testing that we did indoors at T10 level 2. The software PuTTY is a window to see the received data. Otherwise, the "terminal" tab can also see the transmitted data. 

Figure 3 (a). Testing of xstream modem when staying still
Figure 3(b). Terminal Tab of X-CTU

Then, our team brought the transmission outdoors. We headed to 11 Square and get the modems tested out with one of the modems moving away.

Melvin & Siti Staying put
Jingwen, Dzul & En han bringing the modem for a walk :D

Here's the result!
Figure 3(b). Testing of xstream modem while walking
The transmission is successful and signal was not blocked when we moved behind the pillar. 
Now we would need to get the Xstream to talk to the arduino!