This project needs to start making serious headway against the issues that have presented themselves. First up - the gas tank level sensor technique I am exploring is showing a little more promise after a concerted effort. I procured a surface speaker exciter to try and generate vibrations at lower frequencies. This driver was able to excite much lower resonances than the original piezo disk and the low frequency resonances were proportional to air volume in the tank (bottle). Persistence is paying off, but progress needs to accelerate.
I also did a meticulous test of resonance due to blowing across the top of the bottle versus fluid level. This also yielded a proportional relationship between resonant frequency and fluid level. However the actual resonant frequencies from the two different methods of excitation were not the same at the same fluid level - not even close. I suspect the bottle nozzle geometry interacts with the air volume or rather the air volume adjusts the natural vibrations of the nozzle. This unfortunately means I can't use the blown air technique to calibrate resonance versus volume.
Here is a video demonstrating the surface speaker exciting resonances in the bottle:
Actually detecting resonance in a real tank with a microcontroller is going to be difficult based on my findings so far - the resonance frequency is not strongly dependent on air volume, so the numbers fluctuate quite a bit and accuracy is not high, even under very controlled conditions. None-the-less I need to get my interface card on order, so I will just have to make a best guess as to what circuitry might work and get it on order.
As side note for those interested in surface speaker driver technology - here is a demo of the surface exciter working as a speaker playing a song from the radio:
Up next I had to tackle the issue with designing an interface card to implement the features of my design. The expansion cards in the challenge kit were really not playing well with each other or the functionality I wanted to implement, there were heavy pin conflicts with multiple cards vying for use of the same pins. I have not completely decided what is the best way to resolve the radio conflicts as those cards use a lot of pins. However I did press on and designed an interface card that handles all the other functions, so I don't need to struggle with card conflicts.
This custom expansion card handles:
- 2 graphical LCDs
- a 3-axis accelerometer
- driver crcuitry for the gas tank exciter
- signal conditioning for the gas tank sensor
- a GPS
- a couple of mode switches
- and some power distribution
The card has significant protection on a lot of pins, partly because of all the potential pin conflicts and partly because the arduino uno connectors supported by the Nucleo MCU are expecting 3.3 volt signals on this platform, but the uno and many shields for the uno work off 5 volts, which is available on the connector.
Here is a picture of the PCB layout as it stands today:
I have all the parts on order I think, but some have long lead times, so this is going to compress the schedule down the road.
Hopefully I can now start installing the Nucleo IDE and begin exploring how to program it.
Update:
ITEAD makes it easy to follow the PCB build process on their web site - this shows the card is almost done...
Project Links:
IoT On Wheels Design Challenge page
Links to other blogs on this project are included in the first blog:
Top Comments