The first step in testing/developing the circuit is examination of the operation of the HC-05 Bluetooth Serial Communications module. Exploration of how to interface HC-05 Bluetooth Modules with PIC microcontroller via RS-232 communications is given here. The specifics of setting up individual HC-05 modules for use with the LED's (or any other circuit to be controlled via Bluetooth) is given in the following sub-section.
Details of the development of the firmware is also given below in the relevant sub-section.
The Video Section provides video clips of the completed circuit, both on breadboard during initial testing and PCB ready for deployment, in operation being controlled by the Bluetooth application running on an Android phone and tablet.
Testing HC-05 Bluetooth Module via TTL-USB Converter
The HC-05 accepts AT commands (when in command mode) which is useful to test if the module is powering up correctly in the first instance. A USB-TTL converter (I used a $2 converter purchased from ebay) makes it convenient to connect the HC-05 to a PC via USB (see the following photograph in Figure 1). The USB-TTL converter takes power from the USB socket (no other power supply necessary).
The initial step with the USB-TTL converter is to downloaded the necessary USB drivers (if using Windows) which I sourced from the Prolific Technology Inc site (5) which at the time of download was a file titled "PL2303_Prolific_ DriverInstaller_v1.12.0.zip". Unzip the file, click the installer and follow the usual steps for installing the driver software. When the USB-TTL converter is then connected to the USB port of the PC, Windows should do the usual driver installation steps.
The next step is to use a suitable serial port (COM) terminal emulation program to send commands to the HC-05 via the USB-TTL converter. I used "Terminal" which is very useful for debugging serial communication and is available for free (6) (download the zip file, unzip, and use the installer as usual for a Windows program).
The photograph in the following Figure 2 shows how the HC-05 is connected to the USB-TTL converter and then to the PC. In order to send AT commands to the HC-05 via the USB-TTL connection, the small-button on the bottom right-hand side of the HC-05 must be pushed when powering up (i.e. push and hold the button and then insert the USB cable into the PC USB port, when the LED on the HC-05 slowly flashs (~every 2 seconds) the button can be released.
With the USB-TTL connected to the HC-05 and the PC (and the HC-05 is in AT command mode) start the Terminal emulation program on the PC. Connect to the appropriate COM port (baud rate 38400, 8 bits, no parity, 1 stop bit). Enter the letters "AT" (without the quotes) into the transmit field (ensure the CR+LF is selected as equal to CR) and then click send. The letters "OK" should be received back indicating that the HC-05 is in AT command mode. You can then try other AT commands such as "AT+ADDR" which will return the device address of the HC-05.
Note that by using the push button on the HC-05 on power-up causes the HC-05 to enter "mini" AT command mode, which only allows a subset of the AT commands to be used (and a baud rate of 38400 is set and cannot be changed). There are a number of other methods with which to put the HC-05 into "full" AT command mode (which is necessary to use the NAME command for example) (7), but this is not necessary for basic usage. An alternative to "full" AT command mode, is to hold the push button on the HC-05 down while issuing commands. This works for the NAME command, which is useful as generally you want to change the name of individual HC-05 modules from the default "HC-05". Another useful initial command is "PSWD" which allows changing the password from the default "1234".
Success with getting the HC-05 to enter AT command mode and return information to AT commands means that the HC-05 is operational and ready for use in the PIC microcontroller circuit. Note the default settings for the HC-05 for normal communications (i.e. while not in AT command mode) is 9600 baud, 8 bits, no parity, and 1 stop bit.
Firmware Development
The software necessary for the project involves the firmware to be written to the PIC microcontroller (to interface the various hardware components such as analog to digital convertors for sensor input, RS-232 communication with the HC-05 Bluetooth Module, enable real-time clock functionality etc) and the software for the Android device/phone to provide the "app" that supplies the user GUI for control/updating of user input settings etc.
This sub-section discusses the firmware for the PIC microcontroller. A following sub-section details development of the Android device/phone app.
The basic outline of the PIC micrcontroller firmware is given by the following flowchart in Figure 3.
In relation to Figure 3, a hardware timer (timer1 module of the PIC16F722) produces "ticks" via a hardware interrupt, which are used to maintain a real-time clock (RTC) function (i.e. track the year, month, day, hour, minute and second). The RTC then enables the firmware to periodically check "scheduled" events (e.g. update sensor readings [battery voltage and light level] and if such readings need to be stored into EEPROM, and determine if the LED's should be illuminated or not according to the user input/stored time schedule). Data received via the HC-05 Bluetooth Serial Communications module is again hardware driven via interrupts to ensure no received data is lost. Upon receipt of data via the bluetooth serial communications channel, the data stream is decoded into the appropriate command. Finally, the results of the processing loop (i.e. assessment of "scheduled" events taking into account the current time, user input schedule, current voltage level and light level against received user commands and stored settings) are feed into a "state machine" which then illuminates the LED's as necessary.
Real Time Clock Function
Since a PIC16F722 was being utilised to interface with the Android Device/Phone App via Bluetooth/HC-05 module, a RTC function was implemented in firmware (rather than using a seperate chip such as the DS1307 RTC) to more fully utilise the onboard resources of the PIC16F722 and decrease part-count/cost. Further, since the circuit is battery powered, with solar charging, there was no particular benefit to including a DS1307 in this case (and the application is not "time" critical, so in the occasional event of changing battery and or low recharge due to adverse weather etc, re-setting the firmware RTC via the Bluetooth Application is not onerous).
Using the CCS C-compiler, setting up the PIC16F722 timer1 module (the timer2 module is required for use with the ADC - for interfacing the sensors for battery voltage monitoring and light level) is easily performed via the following code:
setup_timer_1(T1_INTERNAL | T1_DIV_BY_8); //prescaler 8
set_timer1(3035); //prescaler=8, 8Mhz, preload=3035 -> Freq 4hz, period=0.25sec
Upon power-up of the circuit, the RTC defaults to January 1st 2017 12 noon. The use of hardware interrupts for RTC timing and RS-232 communication and double buffering minimises the likelihood of data loss during receipt. Nevertheless, the firmware algorithm attempts to maximise the "cycles through the main loop" in order to make the application responsive to user input and avoid buffer overflow etc. Therefore, reading of sensors and checking of hardware status etc is staggered in timing to even out the processor load.
Sensor Input/Analog to Digital Conversion ADC
The monitoring of battery voltage (to enable over-discharge protection) and light level (via light dependent resistor LDR) is performed using the PIC16F722 on-board 8-bit ADC's. As discussed in the Circuit Details Section, an op-amp differential amplifier circuit is used to maximise the resolution available from the on-board ADC when monitoring battery voltage. The following code snippet demonstrates how the PIC ADC's are used to obtain sensor input:
//initialisation
setup_adc(ADC_CLOCK_DIV_64);
setup_adc_ports(sAN0|sAN1,VSS_VREF );
//within CheckScheduledEvents()
set_adc_channel(0); //channel 0 for battery voltage, channel 1 for LDR
delay_us(10); //wait for ADC channel change
adcBattery=Read_ADC(); //batteryValue = adcBattery * 0.008; //8bit - 2.048/255 = 0.008V/count
if (batteryVoltageOkFlag) {
if (adcBattery < MIN_BATTERY_VOLTAGE_CUTOFF) {
batteryVoltageOkFlag = false;}
} else {
if (adcBattery > MIN_BATTERY_VOLTAGE_RESTART) {
batteryVoltageOkFlag = true;}
}
Note the use of the #define's MIN_BATTERY_VOLTAGE_CUTOFF and MIN_BATTERY_VOLTAGE_RESTART. This provides a "hysterisis" so that LED operation does not begin again until the battery voltage exceeds MIN_BATTERY_VOLTAGE_RESTART (12.5V) to avoid "oscillation" or flickering of the LED's due to battery voltage rebound at the set cut-off point (MIN_BATTERY_VOLTAGE_CUTOFF = 12V).
Another item to note is that the firmware maintains sensor input as "raw counts" rather than converted to actual battery voltage. This enables the use of integer values to store the relevant variables in firmware, minimising microcontroller RAM use and the need for "multiplication" which is costly in terms of ROM (the PIC16F722 has limited ROM and no hardware multiplier support). Conversion of ADC "raw counts" is performed within the Android App (and or can be done with the downloaded data on a PC etc).
Pulse Width Modulation PWM
PWM is used to control LED brightness. The PIC16F722 has on-board support for generating and outputing PWM signals using hardware timer2. The following code snippet demonstrates the relevant CCS C code to enable and control the PWM signal:
//initialisation
setup_ccp1(CCP_OFF); //start with PWM off
setup_timer_2(T2_DIV_BY_4,200,1); // PWM signal = 2500Hz with 50% duty cycle
//within code
setup_ccp1(CCP_PWM); //turn-on PWM signal i.e illuminate LED's
setup_ccp1(CCP_OFF); //turn-off PWM signal
case command_changeLEDbrightness:
if (pwmRunningFlag==1) {
setup_ccp1(CCP_OFF);
set_pwm1_duty(make16(tempBuffer[2],tempBuffer[1]));
setup_ccp1(CCP_PWM);
} else {
set_pwm1_duty(make16(tempBuffer[2],tempBuffer[1]));
}
Due to allowing the full range of PWM frequencies to be available to the user, a 16-bit integer is required to store the possible range of values for duty cycle. If a restricted (or pre-set) PWM frequency was used (anything over ~200Hz is sufficient for persistance of vision POV for the LED function), it would be possible to decrease the size of ROM and RAM usage somewhat. It was also found necessarily (not sure why) for the PWM signal to be stopped before changing the duty cycle.
State Machine (actual LED operation)
A "state machine" approach was taken for implementing the overall code. Even though the C compiler/PIC microcontroller does not provide much "native" support for a "state machine", the concept of "discrete states" (e.g. LED's being "off" and/or LED's being "on") and what "discrete events" (e.g. "low light level", "low battery voltage", "scheduled on" etc) affect which state is currently in effect was useful in developing the final firmware algorithm.
As mentioned, the C compiler/PIC microcontroller does not provide support as such for a "state machine". The actual implementation comes down to a series of CASE statements with nested IF THEN clauses that change the value of boolean variables ("flags" indicating the current status of "events" such as "low light level" etc), which then in aggregate determine which discrete state is in effect. For example:
void HandleStateMachine() {
.
.
.
switch (LEDcurrentState){
case OFF: if (batteryVoltageOkFlag && !(LEDmode == OFF)) {
if (LDRenabledFlag) {
if (LDRoverrideFlag) {
if (lowLightLevelFlag) {
changeState=true;} //change state to ON
} else {
if (LEDscheduledOnFlag) {
changeState=true;} //change state to ON
}
} else {
if (LEDscheduledOnFlag) {
changeState=true;} //change state to ON
}
}
if (changeState) {
setup_ccp1(CCP_PWM);
pwmRunningFlag=ON;}
break;
.
.
.
Android Phone/Device Application Development
I use Android based devices/smart phones as the free Android Studio IDE enables producing your own bluetooth customised app "relatively" easily, and does not require any initial cost outlay (assuming you have a PC and Android based smart phone or other device).
The first step is installing the Android Studio IDE which provides the software development environment necessary for implementing, testing and uploading a custom app to an Android based smart phone. Android Studio is developed by Google and is free with download and installation instructions located at this reference (7). There are numerous online tutorials teaching how to use Android Studio and the fundamentals of Android app development (8),(9). For those with prior programming experience, the Android Studio IDE and associated tools makes app development relatively straight-forward. While for those first time programmers, the Android Studio IDE and Java is a good starting point for learning in any case.
After having "mastered" the concepts of Android Studio and the framework behind Android based apps, the next step is dealing with incorporating Bluetooth functionality into an app. Again, there are numerous online tutorials and recommend the following reference as a starting point, which enables simply pairing the Android smart phone with the test circuit and toggling LED's (10).
Once completing this simple toggling of LED's on and off via Bluetooth and Android phone app, extending the concepts to produce the GUI for the LED garden lights is then just a straight-forward use of the various user interface elements provided by the Android Studio IDE, in-conjunction with the appropriate firmware code within the PIC microcontroller to act upon received data to control peripherals as desired.
I won't include any further detailed instructions about the Android Studio IDE, developing apps for Android based phones and or incorporating bluetooth communications funtionality, as there are already numerous excellent online sources, and the depth and breadth of necessary information really depends upon the readers prior experience and requirements.
However, for those with particular questions, please use the comments section below and I will attempt to answer your queries.
As a brief summary, the following is a "high level" overview of the components/approach used to produce the Android App that is used to control the LED garden lights:
- An Android "sliding sidebar" (also termed a "hamburger" menu) is used for the main navigation method.
- "Fragments" are used for each "screen" corresponding to a menu choice. This means bluetooth connectivity between "screens" is maintained (if an "activity" is used for each "screen", the Android life-cycle results in the bluetooth connection being lost when swapping between activities.
- A Floating Action Button is used to show the "help" instructions.
- A couple of noteworthy items:
- The following line of code was required when writing received logged data to the phone SD Card file. This was to ensure that the filename appeared in Windows explorer, in the case that the Android phone was connected to PC via USB cable (and debugging mode enabled).
- MediaScannerConnection.scanFile(getActivity(), new String[]{"/sdcard/" + strFileName}, null, null);
- Ensure that the AndroidManifest.xml file contains "uses-permission" tags to enable bluetooth and use of phone external storage (SD card)
Downloads
Only Logged-In Members can add comments