Dear All,
I am measuring the water flowrate to two reservoirs and sending the result to a central unit by WiFi.
This is a work that has been in progress for about one year where I have to solve dozens of "bugs" caused my lack of understanding the "inner workings" of the Arduino (and C++) languages.
I am a retired Chemical engineer that worked his whole life designing plants using a lot of design tools developed in Fortran IV and HUGE Mainframe computers, but these "litlle devils " are a complete different story.
I am using the SAME snippet of code for measuring the water flowrate in both modules (although the entire code on each module is very different).
In one module the result is 100% in accordance with the datasheet, but on the other (the one that has a more complex code) reports values that are about 2.4 times greater.
That initially happened when I was using DELAY instructions on the code but now I got rid of them.
I wonder if one of the fuctions I am using have a "burried" delay instruction on its code that may be causing this problem.
I apologize for the rather lenghty codes, but I have no clue of what is happening and any suggestion will be welcome.
The flow is calculated as "opflflowrate" and uses pin 7 (INT6) of both arduino promicro modules.
So which code is working good and which is working wrong?
Did you test your wrong counting flowmeter with a small test-sketch that does nothing more than measuring flow?
This would narrow down the problem to either wrong counting code does somehow interfere with some other part of the code or flow-meter has a fault.
Thank you for your Reply Stefan,
I discovered the problem when I loaded the code to the modules that are installed in the field.
So, I started the debugging process on two extra modules that I have for testing.
I use a function generator instead of the Hall Effect sensors since it can provide a constant frequency ( which would be the same as a constant flowrate).
I forgot to mention that the code that works fine is Caixa_Superior.
The attached file is a graph showing the frequency x calculated flowrate for the two modules as well as the expected value according to the sensor datasheet.
As you can see the module#1 calculated flow is higher by a factor of 2.36.
I have had a similar issue in previous versions of the code, which I found out was caused by the use of DELAYS in the code.
So there is something in module#1 code (Cisterna) that is messing with the interrupt but I cant figure what it is
Serial.println(totalLiters);
} // --------this is the end of Optflow Calcs
//********Read level from DP sensor************
rawDp = analogRead(dpPort);
delay (1000);
You can have non-blocking timing based on millis() at any place inside your code.
So what is the reason the insert a delay(1000); between
//********Read level from DP sensor************
rawDp = analogRead(dpPort);
delay (1000);
//********Read Pump discharge pressure via sensor********
rawPdisch = analogRead(P_Port);
if you yourself can read your code well everything is good.
Me personal I prefer real selfexplaining names for variables
dpPort und P_port don't tell clearly what they are.
So it is up to you to explain the functionality of your code.
Please remember that I have no training in microprocessors and other programming languages other than FORTRAN IV, so this project was developed as this: 1- Develop program FlowChart , 2: Find snippets of code on the internet that would do what I need. 3- Adapt the code to my needs. 4- Test the code in "bench", with all the sensors attached to Arduino . 5- Add snippet to the "project". 6- Test "project" in real life (in the Arduinos and the sensors that are installed in their actual places. 7-Correct mistakes.
The delay was left because when I started this project the snippet I used to "learn how to do it" explained that it would be a good idea to "wait some time" to make sure the analog read would work.
Now I have learned that a analogRead instruction takes about 100uSec so the delay would not be necessary.
I have left it just because the same instruction is present in both codes, and it seems it does not cause any problem since one of them works as expected.
Is this assumption correct?
I have left it just because the same instruction is present in both codes, and it seems it does not cause any problem since one of them works as expected.
Is this assumption correct?
I made the same assumption and did not think that the delay() was the cause of the issue.
What do you see for the two sensors in the Serial print statement. How far apart are the sequential values. Does the actual time between readings (when the calculations assume 1 second) reflect the difference you see.
Which flowmeter? If the pulse sensor is a hall effect sensor, you may need INPUT_PULLUP, and interrupt on FALLING instead of RISING, if a reed switch, you may need debouncing. Post a datasheet link for the flowmeter.
Thank you all for the replies.
I will try to answer your questions:
1 - What do you see for the two sensors in the Serial print statement?
I have not paid attention to that. I will post the results after testing
2- Explain what the programs do:
In my cottage the water comes from a natural spring and is stored in one tank, located 800m from the house.
The water is then pumped to a smaller tank near the house located 15m above ground level.
There is one arduino module (plus sensors) near each tank that monitors the principal variables on each tank level, flow, pump current, etc) and transmit them to a third module located inside the house that display the values and alarms if anything seems to be "out of range".
3- Which Flowmeter?
They are hall effect flowmeters like the YF-S201. The datasheet is attached below.
I have tried that before, and for some reason, it did not work.
There was a note on the code saying that it was changed to rising (and the pullup was removed)
However since the code is tested in my "lab" using a function generator (to provide a steady signal to the arduino), I can't say for sure that counting of the falling edge of the signal would not work with the hall effect sensors.
General comments:
I had solved this issue before by including a "correction factor" using the data obtained during the testing of the modules at the lab, using a dataset similar to the one I have attached (the Excel graph).
However, every time I changed the code I had to determine a new "correction factor", which is tedious.
Also, since I have worked all my life with design & troubleshooting I really don't like to "fly blind" and this forum has been an excellent place to learn.
I found that the delay() function was causing the issue, and made several modification on the codes of all modules to not use delay (it interferes with the RF24L01 operation also).
There is only one delay() left, which I will remove, but as I said before, it could not(?) be the cause of this issue since one module behaves as expected.
I suspect that one of the functions that are been used in module#1 is messing with the interrupt, but I do not have the knowledge to find it.
While I am writing this it occurred to me that the current measurement routine Emon is a suspect, since only module#2 uses it. I will try to "comment" this part of the code this afternoon and see the results.
Dear all,
I followed the suggestion given by cattledog and wrote down the millis() values listed by the serialPrint() command.
Quite ashamed for not doing that before...
And as he guessed, the values for module#1 were varying between 2366 and 2347(should be 1000!!)
This confirms the value of the "correction factor" calculated using the measured data shown on the Excel graph which was 2.36.
I don't know what is causing this but I will follow his suggestion and try to use the actual time interval to calculate the flowrate and post the result here.
I will try to comment the Emon function later and see if it is this function that is causing the issue.
Thank for your reply jimLee.
Trying to answer your questions:
1- It seems that the maximum packet size that the nRF24L01 can transmit at once is limited to 32 bytes. I have seen this information in several different places so I assumed that it correct and commented it here in order to remember it.
2 - I don't have the technical knowledge to answer this question. This was present in the source from where I copied this snippet and was kept there.
Should I change it? Why?
