New single channel I2C PCB's have been designed. These boards use only the BMP388 sensors and each sensor is on a seperate I2C bus behind a TCA9546APWR. An initial batch was ordered from @oshpark and were hand assembled by @Steven.Carr. Out of 9 boards, only 3 were successfully assembled. Getting the solder paste right is crucial and is extremely hard to do with such small pad sizes. Not to mention placing the parts with a home made manual pick and place rig. Only 3 PCB's is not enough to distribute to the rest of the team, so we are currently having ScreamingCircuits.com quote us for a batch to be machine assembled.
The whistle was still there even after my attempt to mitigate this problem.
The idea was that I could duplicate the path of the sound, L/R style, and have it cancel out where the paths combined. This did not work.
This may be my fault.
In the original mitigation design I had two equal length/volume paths for the sound. In other words I was borrowing from automotive ICE exhaust system design where they put an H shape between the two banks of cylinders to selectively add and cancel out particular frequencies of sound. Everything being equal (which it was in the original re-design), the waves from both sources should have been identical and canceled out. From that point within the ports, the internal path to the actual sensor went off at a 90 degree angle.
Then, I moved stuff around to generate a smoother transition to the sensor tube from both ports. This resulted in a now unequal path length to the sensor, and I believe that is why the whistle still exists.
Besides being annoying, I think this may actually be contributing to the noise I see in the data at high flow rates (when the whistle sound actually happens)
I have not decided what to do about it yet. I suppose the first change should probably be to go back to the equal length paths I had and see if that fixes it. If it does not, I could always move the whisling to below audible by increasing the 'dead space' for the cam position to sort it out, bor, but I really don't want to do that.
The whistle sound wave, is a pressure wave. It is definitely currently hitting my pressure sensors. My pressure sensors are capable of reporting at a good fraction of the apparent frequency of the whistle sound. This probably means whenever I do hear a whistiling sound that I am not getting the best data that I could be.
In any case, what we have works for testing... with the above potential caveats. In the interest of moving forward, I am currently willing to ignore this part.
One huge step away from everything working together..
The UI got a rewrite and is now classy, eventful, private, and modal. The buttons even do things, and the serial logic for chatting with the core is taking shape. Code is up on Github. Event triggers on variable changes and proper config files would be nice. The former is still giving me issues.
A test on another set shows a significant Venturi effect on our pressure pickup. I need to move it out of the restriction. That should be relatively simple.
The pressure drops during flow almost as much as our pitot tubes are producing. We should get to graphing this today. If the effect is significant enough, we may use it.
We need to generate a coefficient for our sensors when attached to out pitot tubes. To do that we need to have a precise source of airflow.
The current thought process is leaning towards pvc pipe with a piston in it. Move the piston down the pipe and your are displacing a known volume of air, which we can send through our sensor and calibrate it.
Problem is for a 4in pipe and using 5/16in threaded rod (18 tpi) , that rod would need to spin at 8k rpm to move fast enough to hit our upper target for flow. Move to a 6in pipe, and use 1/2in threaded rod (9 tpi) and that number is a lot more reasonable 2k rpm.
The boards arrived from OSHPark yesterday and @Steven.Carr got right to work populating them for reflow. He ran into some issues.
Our placement for the pads to allow either the BMP280/BME280 or BMP388 sensor to live on them was problematic and resulted in failure to properly reflow without the case shorting to one of the adjacent pads/lines. They are too close together.
Steven eventually was able to salvage a few for testing through some careful rework so this is not a total loss though. The good news is the xlator is doing its job, and we have two sensors which are working in the right configuration now to move forward.
This will enable us to test a few different pitot tube configurations to determine the ideal gain/flow tradeoff. Bigger tubes give us more gain, but this will also increase the restriction through the pickup reducing our overall flow.
I'll be modeling a range of pitot tube sizes for him to try out. We will still need some form of calibrated flow to compare these though. We'll have to work on that. Worst case a garbage bag full of air would give us a calibrated volume from which we could extrapolate the flow, but that wouldn't give us very much to work with. We'll need something better.
Daren Schwenke
