Senior design presentation

Link to presentation.

Updated schematics and board layouts

Here are the schematics and board layouts updated to account for the changes we had to make to our boards post-manufacture.

Pygmy meter board:

Cap-wire board:

Project Update (Abhijeet, Aakant, Gregg)

Fixed PCBs

The LEDs for power and communications were not soldered properly to the board. This caused multiple discrepancies throughout the PCB which cost us significant amount of time. To fix this issue, we re-soldered the LEDs and checked each and every connection on the board.

Instrument Interfacing

We started working with the pygmy meter and cap-wire instruments in one of the IIHR’s flumes. We discovered that the pygmy meter setup was not working as we expected it to. The line from the instrument was only being pulled up to 3V instead of 5V, thereby causing discrepancies in our readings. For the cap-wire instrument, we discovered that the length of the co-axial cable causes a change in capacitance which affects the readings.Also, the connections to the actual instrument itself were not perfect, leading to further inaccuracies. For now, we have on cap-wire instrument working with our setup.

Software

Once we started obtaining the reading, we changed the software UI to account for calibrating the cap-wire instrument and showing proper chart for the pygmy. To obtain proper readings, we also timed our program to query each of the devices three times per second. This allows us to gather more precise data. We also added the functionality of saving data to a text file, and showing the data on a table in the UI in real time.

Demonstration

We demo-ed our project to Professor Curry showing a working prototype.

Next, we need to work on obtaining more precise readings from both the pygmy meter and the cap-wire probes. We also need to improve the analog out for the three devices.

 

Project Update (Abhijeet, Aakant, Gregg)

Creation of enclosures for PCBs

We submitted our PCBs to the machine shop for the design of the enclosures. This was done to satisfy our user requirements. The design was enhanced for water resistance.

PCB testing

After obtaining the pygmy meter PCB and the two cap-wire PCBs, we populated the boards with components according to the schematics. Afterwards, we found a few issues with the wiring to the serial chips in our traces on the boards. We fixed these with some post-production wire soldering.

Flume

For testing the accuracy of our designs, we have obtained access to a flume from our sponsor. This will allow us to control water and wave velocities to verify the achievement of our specifications.

Capacitive wire instrument firmware

Since the frequency of the square waves outputted by the 555 timer was in the range of a few hundred hertz rather than a few hertz, the firmware code for the cap-wire instrument had to be modified from the pygmy meter firmware code. Instead of counting timer overflows within one period, we decided to count the number of periods in one second. This led to much more accurate readings.

Considering the advice given by our sponsor, we decreased the values of the resistors used with the 555 timer to prevent loading the IC. This also increased the resolution of our readings because it led to a finer increment on our capacitance scale.

GUI enhancement

In order to make the GUI user-friendly, we added a chart for the river water reading, another for the current water depth reading and a chart for the wave velocity reading. We also added the current readings to text fields so that the user can observe the values without the need to switch charts.

Update of serial interfacing

Since the communication port is not constant, we added the functionality of run-time configuration of the communication port, baud rate, start and stop bits. To implement this, we had to modify the design of the UI interface and the serial communication object.

Addition of mechanisms to work with different capacitive wire instruments in software side

We realized that the capacitive wire instruments used may be changed and taking that into consideration, we added the functionality so the user can add their capacitive instruments’ values to work with the software. This included calculation of the new linear slope between the frequency and change in depth. We also added a calibration functionality where the software spends a specified amount of time gathering information on the current water depth and uses that information to calculate future velocity readings.

 

Update: schematics

Pygmy meter board schematic:

Cap wire board schematic:

Progress Update (Aakant, Abhijeet, Gregg)

Serial interface – sending and receiving on the same bus

As mentioned in our previous post, we weren’t able to implement the send and receive functionality of our RS-485 communication simultaneously. Based on our sponsor’s recommendation we jumped the receive and transmit pins on the PC side and used one max485 chip per microcontroller to communicate.

Serial interface – communication protocol for multiple devices on one bus

We sought to make two devices work on one bus. We needed to avoid bus contention issues – if both send at the same time, the PC cannot receive the correct data. To resolve this issue, we created our own link layer communication protocol in which the PC sends a unique address for each microcontroller requesting it to send data. This worked wonderfully.

New component – LEDs!

To improve the user interface on the hardware, we added indicator LEDs to show when the device is powered on and when it is sending or receiving data.

Obtaining instrument readings and establishing accuracy

We previously were not able to send the data reading from the microcontroller in real time. We resolved this issue by changing our firmware design for obtaining the instrument readings from an interrupt based system to a polling based system. Another reason for this design change was that the external interrupt pin and the analog PWM output pin were the same – only one feature could work on that specific pin. Also, instead of getting the number of switch closures (high-to-low transitions) per second, we measured the time between each switch closure. This time was measured in terms of timer overflows, as the timer usually overflowed thousands of times between each switch closure. This enabled us to achieve the desired accuracy of 0.1ft/s. However, instead of computing the speed on the microcontroller, we decided to send the number of times the timer overflowed between each switch closures as the PC has better accuracy.

Establishing support for JavaFX

In order to provide a more user friendly and sophisticated look to our software application, we decided to utilize JavaFX. We downloaded the JavaFX api and installed the newest version of the JavaFX platform compatible only with Netbeans 7.1. In order to run the JavaFX applications on the PC, we updated the JRE. The installation procedure for establishing JavaFX support can be found here.

Learning UI elements in JavaFX

Once we established support for JavaFX, we experimented with the Netbeans JavaFX samples to learn how the UI elements can be setup in a fx application. This involved learning about animations, stages, scenes, etc. According to our understanding of the samples, each application has a stage which contains a scene node. Any UI elements in the application are attached to the scene. Documentation for JavaFX 2.0 can be found here.

Acquiring readings in JavaFX through the serial port

As of now, our application has two classes. The JavaFX class comprises of the GUI elements, and instantiates the Serial Interface class which obtains/sends data from/to the MCU. We were able to obtain data following the communication protocol mentioned above using the Serial Interfacing class. To do so, we send the assigned MCU address every second on the RS-485 bus and obtain the respective reading from that MCU.

Creating JavaFX charts and integrating the chart with the serial interface.

Once the Serial Interface class obtains the reading (time measure) from the Pygmy meter instrument, we calculate the velocity. The JavaFX class instantiates the Serial Interface class and adds the reading the Pygmy meter chart as shown here.

Creating PCBs

We submitted designs for PCBs for both the pygmy meter circuit and the cap wire circuit to the eshop for manufacture. The corresponding parts have been ordered from digikey. Here are the board layouts.

pygmy:

cap wire:

Project update [Abhijeet, Aakant, Gregg]

1) RS-485 – sending and receiving data from/to the microcontrollers.

We have been working on the Rs-485 communication between the microcontroller(s) and the  computer. We initially thought we would have to send data from the PC to the microcontroller to control the flow of data on the bus. Under this configuration, the PC would send a byte on the bus which would identify which microcontroller  would send its data.

First we tried to use a single max485 to send and receive data. Under this configuration, the microcontroller could send data, but could not receive it. This was because the bus was default high while sending, but was default low while receiving. Thus the max485 chip could not decipher the default low behavior of the bus.

Then we tried using two max 485 chips for a single microcontroller: one for sending data, one for receiving. The receiving chip had its bus lines inverted under this configuration so that it could get default high input. Initially, we used an inverter chip to achieve this inversion. Then we realized we could simply reverse the bus wires connected to this chip to achieve the desired effect. Using this configuration, the microcontroller could send, but it could not correctly identify the data it received. This could be due to the receiving max485 chip not outputting the data that it read from the bus correctly or a bus issue.

We contacted our sponsor and he suggested an alternative wiring for the RS485/RS232 converter. We plan to work on this next.

2) Improve accuracy of circuit timing

Initially, the microcontroller was set-up to count the number of switch closures/high-to-low square wave transitions on the input pin every second and send that data over to the PC. However, due to the nature of the square wave and the fact that the switch closure occurred every revolution, our accuracy was to the closest foot per second. Since the requirements need an accuracy to the closest tenth of a foot per second, we came up with another solution to achieve this accuracy.

Instead of finding the switch closures per second, we decided to find the time elapsed between consecutive switch closures. We then sent this data to the PC via RS-485 standard. This would be more beneficial as the PC can then calculate the inverse of the received value to get an accurate reading of the velocity of the water to the nearest foot per second. We observed  a difference of about 20-40 milliseconds between the actual time between switch closures and the time measured by the microcontroller. We can simply add a 30ms offset to the received data to account for the discrepancy. This would result in just a -10 to +10ms accuracy range. Since the relation between the revolutions per second and velocity in feet per second is about 0.9:1, we can see that we can be off by a maximum of 90 milliseconds to stay within the accuracy range. Thus, by this design we should be within our accuracy range.

3) Circuit power supply decoupling

Initially, we had a separate breadboard for the capacitive wire circuit and the pygmy circuit. We pursued this plan of action because we were running out of space on the small breadboards. After integrating the 2 microcontrollers and the 2 max485 chips on the new breadboard, we observed that the serial communication and the clock speed of the microcontrollers became faulty. After careful re-examination and intra-disciplinary communication, we decided to add a decoupling capacitor between power and ground on the microcontroller chips. This reduced high frequency noise on the power supply and proved to be of utmost utility in resolving our issues.

 

To-do:

1) Implement inter-circuit RS-485 communication

2) Establish support for JavaFX for the user interface.

Project Update (Abhijeet, Aakant, Gregg)

For the RS-485 implementation, we obtained the MAX485 chips and a RS-232 to RS-485 converter from our sponsor. We then proceeded to implement the RS-485 circuit for the Pygmy meter circuit using the MAX485 chip. We chose to use header jumper cables instead of twisted pair, since we did not need the prototype to have long range communication capabilities. Since the cables did not have high impedance, we did not use termination resistors. We did not use any fail-safe bias resistors, as it was already implemented in the MAX485 chip. Finally, we were able to successfully send the data from the Pygmy meter to the PC. Next, we will work on making both the circuits send data to the PC using RS485 simultaneously.

To implement the analog output, we first used the command PWM in the firmware. However, the output was not continuous (infinite cycles) so instead we chose the HPWM command. Based on the settings (changing duty cycles, 1 kHz frequency), we made a simple low-pass filter from an RC circuit, using a time constant 10 times the period of the pulse width modulator. Before implementing the RC circuit, we were considering to use an R-2R ladder, but decided otherwise because it would require more pins on the MCU.

The Cap-wire circuit is essentially the same as the Pygmy meter circuit. The difference between the two is, in the Cap-wire circuit, rather than connecting the instrument directly to the micro-controller we have a 555 timer which outputs a square wave to the micro-controller. Since the Cap-wire instrument is a variable capacitor, we connected it to the 555 timer to obtain a waveform whose frequency varies. Theoretically, we will be able to determine the water level based on this frequency.

We followed the direction on the datasheet for the astable operation (schematic shown above) which produces the square wave. Next, we had to figure out the values of Ra, Rb, and C for using the following equations:

frequency = 1.44/ (Ra +2Rb)C

duty cycle = 1- (Rb/ (Ra +2Rb))

We decided on the following values:

Ra = 36 K Ohms, Rb = 3.6 M Ohms, and C = 200 – 800 pF

Consequently, we obtained the following values:

Frequency = 495 – 1980 Hz

Duty Cycle = 50 %

We the capacitor ‘C’ will be our Cap-wire instrument in the final design. For the purpose of prototyping, we used a known value of 660 pF. We observed that the frequency changed as we put a different capacitor within the 200-800 pF range.

For next week, the things to work on are:

1) RS-485 – inter-circuit communication

2) Improve accuracy of circuit timing

3) Integrate RS485 and analog output functionality.

4) Integrate the Pygmy circuit and the Cap-wire circuit.

Project Update – Aakant

I have updated the MAX481 wiring diagram as shown below:

As of now, I do not know the value of the termination resistor (between pins 6 and 7) because that depends upon the cable we use to connect the components (not yet known).

Also, I do not know whether we need the two other biasing resistors – we might need them to catch errors or they could be already built in (documentation is not very elaborate on this).

I will discuss this circuit with the team in the meeting tomorrow.

Also, I have posted a new resource (by Texas Instruments) for the RS-485 specification (Very helpful). As usual, the link to the resource can be found on the resources page.

Project Update – Aakant

This week, I worked on:

1) Installing MPLab on my netbook to be able to program the microcontroller – Abhijeet helped a great deal in setting it up as he had previous experience in this matter. After installing, I ran the existing code and verified that the install was completed successfully.

2) Next, I worked on getting the number of high-to-low transitions in the function generator per second.

a) Since our pygmy meter would be similar to the function generator, we varied the frequency of the function generator between 5Hz to 3kHz. We had to add a DC offset to the function generator and make sure that the voltage levels are between 5V and 0V. We encountered weird behavior in the oscilloscope (DC offset apparently had no effect). Later on we figured out that we had to turn on the DC coupling in the oscilloscope.

b) After working with Gregg and Abhijeet to get the time between two consecutive high-to-low transitions using interrupts, our readings were off by a magnitude of atleast 10. Abhijeet suggested to use the polling method to get the time between two consecutive high-to-low transitions. Based on the suggestion, I tried to get the number of high-to-low transitions per second because it would be easier to plug-in the equation for getting feet per second. Using trial-and-error, I was able to get the readings to 0%-1% of the actual value (higher the frequency, lower the accuracy).

3) For the RS-485, with Abhijeet’s help, I found resources on how it works in the Resources page. My suggestion was to use the MAX481 chip – because it has a low-power shutdown mode and we only needed a half-duplex communication link. Since RS-485 is only a physical layer protocol, we will need to establish a higher-level protocol for the required communication to work effectively. Here is a diagram of the proposed MAX481 chip wiring:

Next week:

1) Get the connectors and wiring established for rs-485 communication. Also, need to figure out whether biasing resistors are needed to prevent erroneous data.

2) Figure out communication protocol between devices.

3) Get an RS-485 to RS-232 converter or RS-485 to USB converter for PC communication.