Week 4 - Continuation of Bluetooth modules and working on speed sensing & voltage sensing

Hc-05/06 Bluetooth modules

Finding out the problem...

Most of the week is spent on troubleshooting on the Bluetooth and Wifi modules. Both faces a similar problem: unable to initiate AT commands while in AT mode. After spending an entire week on troubleshooting, the problem has been fixed. No matter what was done, or any command's issued, none of the commands worked at all, even though the Bluetooth modules were in AT mode. It is most probably due to some settings that were done in the HC-05 that permanently binds the master and slave together, hence disabling ALL activities other than communication purposes (sending and receiving to and fro). It is likely due to either of the following two commands that blocked ALL the AT commands:

AT+BIND=3014,11,192230           // to bind
AT+CMODE=1 // Set the HC-05 to only connect with paired devices

The first problem...

Figure 1: Pinout of HC-05 & HC-06

During the first few days of troubleshooting, one of the many manuals of different similar models of the HC-05, it is written that the RESET pin is "activated" by pulling it low (supplying GND to the pin). However, it is uncertain of what it will actually reset. Fearing that it may damage the board, the idea of trying it out was scrapped.

Mr.Joe suggested that the Bluetooth modules be powered up and connected through the TTL Serial Adapter module (FTDI-232) without the Arduino pro mini and program, which still did not work out.

Towards the end of an entire week of troubleshooting when everything has been tried several times and there is no another way(s) to break the "permanent binding" of the two modules to issue the AT commands. To our surprise, the AT commands finally worked  again after "resetting" the board.

The second problem (similar to the 1st problem)...

The problem came back, AT commands do not work for both the HC-05 and HC-06 despite having correct baud rates programmed. Mr.Joe's suggestion was tried again and it worked properly. After a few rounds of testing, it is concluded that the AT commands only work without any program (in our case). Connecting to Arduino shouldn't affect the issuing of AT commands, however, it is likely due to some settings of the Bluetooth modules or some parts of the program, or both, that interferes with the AT commands.

Figure 2: AT command problem (no feedback)

The third problem...

After setting the Bluetooth modules successfully and programming the boards properly with the correct code and baud rate, the messages sent and received are in weird symbols. This means that the Baud rate between the two modules is not the same.

Figure 3: Incorrect baud rate problem

Solution...

Setting up the Bluetooth modules - Supply the VCC, GND, TX, RX pins of the HC-05/06 through TTL Serial Adapter on a breadboard, without the Arduino connected, as shown below:

VCC  - VCC
GND  - GND
Tx      - Rx
Rx      - Tx

In the case that this solution does not work, supply a Low (GND) input to the RESET pin (11) of the HC-05, before trying out the mentioned solution again.

Fixing the baud rate - Under tools of the Arduino IDE, swap the processor between ATmega328 (3.3V, 8MHz) and ATmega328 (5V, 16MHz). E.g. Change the processor to the 3.3V 8MHz when weird symbols are appearing for the use of 5V 16MHz. This is due to different boards having different frequencies. However, in this case, we have found that for the very same board used, the 8MHz may be used and the baud rate is correct, and when it is re-powered up, the 16Mhz is being required instead.

To sum it up, when issuing the AT commands to set the HC-05/06, it is advised that they are connected through the TTL Serial Adapter on a breadboard without the Arduino, with pin 34 for HC-05 to be high. However, when entering the communication mode, pin 34 has to be low, and the Arduino board is required.

Speed-sensing

We looked into the programming of the SunSPec4's Telemetry group and tried to understand their programming and this is what was found from their program:

mAin = analogRead(A6); //read voltage from analog input in terms of bits

ImotorA=(((mAin/1023.0)*5.0)-2.5)*15.0;

//((((mAin)/1023.0)*5.0)-2.5)*(30.0/2.0);

//*(0.0732421875))-37.57); //NEED CALIBRATION

It is unsure that what the value of (30/2) represents, we will be going to the workshop on the following Monday to test out the pin 27 of the motor controller.  The pin 27 outputs the pulses generated per revolution of the wheel, which is required for speed calculation, 

Voltage-sensing

The original idea was to use a simple and small optocoupler board to separate the "hot" GND and the "cold" GND. However, it is decided that it will be too dangerous to do so as a voltage supply of more than 100V will be supplied to the circuit. The circuit is exposed and accidental contact can cause electrocution, there may also be arcing which proves another possible source of danger. 

We sought advice from Mr.Than from the PV group, as he had worked a FYP group working on an optocoupler for the solar side too. As suggested by Mr.Than from the PV group, two possible ideas are as follows:

1. Using a chopper to step down the supply voltage, then output it to the supply of optocoupler, hence diminishing the danger hazards as mentioned above.
2. Using a hall-effect current sensor in place of voltage-sensing circuits, then program it with the ohm's law to change the current sensed to voltage and display it. 

The second method is the safer method as compared to the first, however, it is also less accurate. After some discussion between Mr.Than and Mr.Kenny, they are keen on going on with the third method:

By using an industrial-grade voltage-transducer - CR5300. It is relatively easier and safer to use this device to separate the High-Voltage and Low-Voltage sides. Mr.Kenny is currently looking into purchasing device to test it out, and the device should arrive by December.