- This topic is empty.
-
Posts
-
In the process of changing the program data structure to allow per-station water time, I thought about this question: is it possible to fit ‘station water time’ in 1 byte (0 to 255)? Currently the water time takes 2 bytes (0 to 65535) and it’s in granularity of seconds, so it can represent any time from 0 to 18.2 hours in steps of seconds. To fit it in 1 byte, what would you do?
* Option 1: use granularity of minutes, so it can represent any time up to 4.25 hours in steps of minutes only
* Option 2: use granularity of 15 seconds, so it can represent any time up to 1 hour in steps of 15 seconds
* Option 3: use a non-linear scaling: from 0 to 59 it’s in granularity of seconds, then it changes to granularity of minutes. So this can represent seconds up to 59, then minutes up to 196 (255-59).
* Other options?Basically I am trying to understand common needs on the accuracy of water time: do you ever need to run a station for just a few seconds? How important is it to be able to set a water time of, say 5 minutes 25 seconds, 20 minutes 50 seconds etc? Thanks!
Longest run time currently is 3 hours. I do have cycles that run all day long…like15 minutes running every 4 hours 1am until midnight.
The only use case I could think of when seconds are required is for misting. It seems that 15 seconds minimum fractions should suffice.
@TechFan: the number of times a program runs doesn’t matter (that’s stored in another variable), what I wanted to know is the water time within a single program run. So in your case , you have one example of 15 minutes, and another of 3 hours. (and just saw that you said you don’t need granularity of seconds, thanks).
Assuming this byte only represents the user selected time for a circuit, i.e. It is not the actual running time, as that must consider the user set program percentage and possible other factors.
Here are variations on option 3:
A. With minutes and hours; This would allow the user to set a circuit to run as long as 196 hours and 59 minutes, in 1 minute increments.
B. With 30 seconds and hours; This would allow the user to set a circuit to run as long as 136 hours and 59 minutes and 30 seconds, in 30 second increments.
C. With 15 seconds and hours; This would allow the user to set a circuit to run as long as 16 hours and 59 minutes and 45 seconds, in 15 second increments.For my uses, the 1 minute increment is the best choice. This is because it would be the easiest to set, while not limiting the running time.
@iDoug: you are right that the actual running time is in granularity of seconds so water percentage can be applied without losing accuracy. The 1 byte restriction is mainly for efficient storage (’cause the microcontroller has limited EEPROM size). Because water time per station takes up most of the program settings, if we can fit it in 1 byte instead of 2, that can provide almost twice as many programs, which is desirable for people with a lot of stations.
Is it important to cover run time longer than, say 8 hours? I mean, if you need to run it that long, you can always break it into two programs that run one after another right?
@iDoug: here is another version based on your proposal: the first 2 bits represent units (second? minute? hour? day?) and the remaining 6 bits represent value. This will waste some values (like 24 hours and 1 day is the same), but simplifies the conversion.
Would that limit the user in precision of input?
Don’t forget you have the hard part of actually coding this algorithm, we have the easy part of coming up with the algorithm.
Side note: At the top of Google’s core principles is: “Focus on the user and all else will follow.”The simplest approach is to let user input any time they want, and it’s the firmware’s job to quantize the value as necessary. But this may cause some confusion (like they may be surprised that 3 minutes and 10 seconds get rounded to 3 minutes). So the better approach is for the UI to match the firmware: for example, the user can put in any number in the ‘second’ box, but as soon as the ‘minutes’ box has a non-zero number, the ‘second’ box is disabled to reflect the fact that beyond 1 minute the accuracy become minutes.
Or have a spinner/drop down with unit choice and only one box for numbers.
Sent from my iPhone using Tapatalk
I will have to redesign the input completely to handle the non-linear method.
Using the latest method (defining the units in two bits) lets me show a value input with a unit selection. I think this would be easy from a user perspective.
Update: This is exactly what TechFan just wrote.
No, the UI won’t be affected much, because the conversion back and forth is done on the firmware side. The UI can send any value to the firmware, and it’s up to the firmware to decide how to store it; similarly, when the firmware sends value to the UI it gives the UI the decoded value. [edit: yes if we are going with the value + unit approach, it will involve a UI change]
Another question: since ‘seconds’ is not very common, do people care about the accuracy of 1 second, or would 5 seconds suffice?
@ray wrote:
Another question: since ‘seconds’ is not very common, do people care about the accuracy of 1 second, or would 5 seconds suffice?
If we do units + value do we need to further compress seconds? I’m just curious.
If we did non-linear my plan was to show “seconds” and after 59 (at 60) switch the value to 1 min and change the lable for units to “minutes” and keep moving up as we increase. Same thing as we decrease the value.
@ray wrote:
@iDoug: here is another version based on your proposal: the first 2 bits represent units (second? minute? hour? day?) and the remaining 6 bits represent value. This will waste some values (like 24 hours and 1 day is the same), but simplifies the conversion.
After thinking about this idea, I am confused. It appears you are saying that the user would select second, minute, hour or day. The the value of that would be a maximum of 63 as 6 bits has 64 values. Which would mean if a user selected 1 hour and 30 minutes the function would throw an error as this exceeds the lowest common denominator of minutes which has a value of 90. In other words the user is limited to 63 seconds OR 63 minutes OR 63 hours OR 63 days. What did I miss?
@iDoug: the user has no way of selecting 1 hour and 30 minutes, because there are only one input value box, and one dropdown list to select unit.
Wouldn’t it be best if the UI sent a time value and ray’s function stores that value into a byte and returns true for success and false for failure. How that time value is stored is all inside the function and should have no bearing on the UI.
How that time value is stored is all inside the function and should have no bearing on the UI.
Sure, as I said before this is fine; but if we are to adopt the “value + unit” option , then the UI can be changed to match that right?
IMHO: It does make for an unusual UI. Wouldn’t that also mean an odd API for others? Shouldn’t all time values be passed in the same manner? If so, can all time values be limited to 63 units?
Additionally, you will have to explain your logic to every user/coder that wants an odd variation of these units, i.e. 90 minutes. As you have told me, this is not a pleasant task to justify your logic.
Look, the firmware does its own independent checking, so if you throw 65 minutes to it it’s just going to round it to 60 minutes because it has no way of representing 65 minutes; and if your throw 120 minutes to it it will convert it to 2 hours. It always does its best to represent whatever value you pass in. I agree with you that the firmware functionality should not be dependent on the UI to do error checking for it.
What I meant is that if the firmware cannot represent 65 minutes, why letting the UI leave this as an option? I think it’s not ideal for users to set 65 only to find out it’s rounded to 60. So what I am saying is that if the UI can do it, why not?
I agree with your logic about how the UI should behave. I disagree with the firmware not allowing 65 minutes. What happens when a coder wants to expand the log functions to allow for a display of 90 days or months or years? None of this would be represented in the firmware.
By making your unique variation of time available to the UI you are setting a standard for the project. Are you prepared to constantly justify this standard?
- You must be logged in to reply to this topic.