05/23/2020 at 09:31 •
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.
05/02/2020 at 02:12 •
The venturi restriction plus the short tube going to the sensor was just the right geometry for a good whistle. That was annoying.
I added another pickup tube in the venturi, and connected them. I am thinking this will cancel the waves where they meet.
As a last minute thought I made the geometry not symmetrical as well. That might actually work against me now that I think about it.
Edit: FFF version, the whistle was gone. SLA version failed on first print due to low resin. It will be ready in the morning.
04/28/2020 at 09:19 •
We are losing some volume with respect to time.
This could be caused by some simple things, some not so simple things, and one impossible to fix thing.
We will be checking each of those boxes tomorrow. Too bad It seems we will have to build a flow meter, to test our flow meter.
Edit: There was a hole in the balloon. A pretty big one. Duh..
04/27/2020 at 02:04 •
FInished a venturi version.
These are the internal cutouts.
04/26/2020 at 08:33 •
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.
04/25/2020 at 16:36 •
We printed some pitot pickups in clear. Oooooo..
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.
04/11/2020 at 15:17 •
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.
Working on it.
04/10/2020 at 21:38 •
We had some more copies of the body printed the other day on SLA.
The snap off bit for the lower pitot still liked to take a bit of the tube with it when printed on low resolution SLA printers.
I made it a bit weaker and the pitot a bit stronger.
Also sorted the lower overhang making it a big more gentle, and matched the body width to the new PCB width.
04/10/2020 at 06:37 •
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.
04/07/2020 at 02:45 •
I love it when data makes a nice line like that.
Given our BMP388 sensors are about 10x more sensitive, I think we might just be ok.
Still waiting for our boards from @oshpark, but they should be here in 2 days. I can't wait...