BED WETTING SIMULATOR updates

Does this project need a logo? I'd love a pixel art diaper or something like that.


  • Total voters
    53
Cottontail said:
Great write-up. I'm really looking forward to an opportunity to try this concept out, whether it's Arduino-ized or "dumb."

For as infrequently as I manage to sleep in diapers, I'd want the probability of an "accident" to be 100%, in any case. I do slightly prefer the idea of a discrete wetting event to a long, slow dribble, but the latter might still create the desired effect for me. Certainly the complexity of the setup is hard to beat.

Absolutely. I think 100% wet is the only way to go through life. I included a 40% chance of a dry night in my profile/scenario code just because that seemed to be in line with the intent of the overall project.

My only problem with this morning's adventure is that it's given me a data integrity conundrum. The Camelot was holding 3,809 ml by the end, beating my previous record of 3,776 ml with the Camelot which was also my record with any diaper for all time. Do I change the max capacity to 3,809 in the wiki or do I consider this cheating since 3,000 ml of that was water?

There are 287 max capacities listed in the wiki and each one was from wearing and wetting a diaper or using a baby diaper or cut-open pullup as a liner, usually with several tries per diaper. I wanted to do something different from those tests where they put a diaper in a tray and drip on it until it leaks or something. My way may not be easily reproducible and it's a lot of work, but it's genuine. It's personal. It's all my own pee. A man must live by a code :)

I care only about max capacity because it avoids the subjectivity of "two good wettings" or "several hours". It may not be the most useful thing to know about a diaper; it's just that it's the thing I can test.

But it can be really inconvenient to use a diaper to the max. For the super premium ones like Tykables that can mean 24 hours in the same diaper, and often it means abandoning a test before it's done because life gets in the way. Now that I've, er, broken the seal on the idea of enhancing the content of my diapers with some amount of warm water I could use this to test more products in less time. It's still adding liquid in the right place in a diaper that's actually being worn, but I don't know if it's still a valid test.

I suppose I could re-test some of my better known diapers with some fixed amount of water like 1,000 ml added a little at a time in addition to honest pee and see if I get the same results.

Looping this back to the project, one interesting aspect of it is that an automated wetting system could be used to test diapers in real-world conditions such as in bed, sitting, or standing; while at the same time using a precise and replicable pattern and volume of wetting whether that's floods or spurts or something else. I could test a different diaper each night, using the system set to a specific pattern that was the same night after night. Since I don't wet in my sleep, this would mean hitting each diaper with the same conditions. I suppose the result each morning would be whether there was a leak, and if so how much, say by weighing an underpad.
 
  • Like
Reactions: LainIsLain
This is all surrounding the next step which is to integrate a preference system for wetting events.

Issue one is the subjective idea of what "wet" is. Wet to you might mean double or triple wet to others. So the device will need to know what "wet" means to you. Of course the manual interval/duration system can be used but I want something a little more user friendly.

So in order to be effective the device needs to know how much liquid is transfering either with or without a flow sensor. Since the device will know how long the solenoid/pump has ran it can also know an approximation of the total liquid if the user can tell the device ahead of time what the flow rate is. There will need to be some instructions of course. Something like turn solenoid/pump on for one minute and measure the liquid. Enter that in liters/min. Set what "wet" means to you. If wet means 2000ml over the sleep time then depending on the preference (quantity per wetting event drips, spurts, full release etc..) the device can calculate the needed number of intervals and durations in order to get to 2000ml over the sleep time. Or even a random amount for possible leakage.

Can't wait to get this part nailed down. 😳 🤗
 
Last edited:
  • Like
Reactions: WillFord384
Didn't have much time tonight. Made one minor change about how the running time was derived. The way I was doing it was very sloppy and will be problematic when reading from sensors.
 
Last edited:
WillFord384 said:
Do I change the max capacity to 3,809 in the wiki or do I consider this cheating since 3,000 ml of that was water?
Absorbency changes based on salt content of the liquid, especially in high SAP diapers. The ISO test everybody uses involves literally dunking the diaper in a bucket of water for several minutes and then weighing it dipping wet. If you used regular water and not a saline solution, I'd say the numbers don't count.
 
  • Like
Reactions: WillFord384
irnub said:
Absorbency changes based on salt content of the liquid, especially in high SAP diapers. The ISO test everybody uses involves literally dunking the diaper in a bucket of water for several minutes and then weighing it dipping wet. If you used regular water and not a saline solution, I'd say the numbers don't count.

OK, thanks. I can try a homemade saline solution. The old record prevails.

It's just as well. I figured diaperfans around the world were going to be up in arms if their beloved Camelot was knocked out of first place by some upstart Camelot :)
 
Last edited:
LainIsLain said:
Update BedWetter V0.2.4

Added pure random function. This will give random wetting times and durations using the entered "intervals" and "duration" as limits. So if you choose 10 wetting intervals and a duration of 10/secs, the randomness would be 10 random times over the total sleep time with random durations at a maximum of 10/secs.

The chance wetting feature is still not done and will work on that next. Then planning the profile system.

EDIT: FYI I'm using randomSeed(analogRead(1));. This is seeding the randomness with data from the analog pin 1.
Hi, as mentioned i would start/continue testing.
In my last post i gave the test results of version 0.2.1 which was perfect as mentioned.

Now with the latest version i have a malfunction device.
Here are some data/results.

Options Set:
Sleep Time: 1h
Delay: 1m

Wet Change: 30
Wet Interval: 30
Interval Dus/s: 30

Prime: OFF
Output Pin: 3
Duty Cycle %: 3
Duty Pulse: 25



BedWetter 0.2.1 = OK
BedWetter 0.2.2 = OK

Output Pin gets activated(with above settings) on the count of:
(61 on, 91 off, 181 on, 211 off, 303 on, 333 off...

BedWetter 0.2.5 = Not OK

As from version 0.2.3 / 0.2.4 i have a malfunction device.
Output get's not activated anymore
.(cannot set Wet Change to 100%...Max only 99%)
Please let me know what you need from me to help solve/debug the programm.
Thanks for the effort, really enjoy doing this together.

TestResults:

BedWetter_0.2.51

Sleep Time: 1h
Delay: 1m

Wet Change: 99
Random: NONE
Wet Interval: 30
Interval Dus/s: 30

Prime: OFF
Output Pin: 3
Duty Cycle %: 50
Duty Pulse: 25


Test- Output Pin gets activated(with above settings) on the count of:
61 on, 73 off, 86 on, 91 off, 99 on, 111 off, 123 on, 126 off, 136 on, 139 off
 
Last edited:
  • Like
Reactions: WillFord384
If you leave the WET CHANCE option 0 that is effectively 100%. I have most of the variables roll over at 99 back to 0 to make things easier. I couldn't see a reason for the need to set a 0 chance of wetting so if the chance is 0 then the program ignores that setting and the chance is effectively 100%.

The WET CHANCE is calculated one time at the beginning of the run. Meaning if you have 50% entered there is a 50% chance the output will be activated at all during the night. I hope that's the behavior you wanted. If you'd rather have a chance weeting for each event then I can change that.

Your results for v0.2.51 are probably correct. One thing I see is you have the duty pulse at 25, duty cycle 50%, interval duration 30, and interval 30.
So the program is dividing 1 hours by 30. So that's 1 activation every 2 minutes with duration of 30 seconds. During that interval the duty pulse is 50% of 25 sec. So for each interval the output will activate for 12.5 seconds then turn off for 12.5 seconds. This is a very long duty pulse time! The same effect would be if the interval duration was set to 13 seconds and the duty cycle and pulse were left 0.

You have chosen a very long duty pulse time. I'll have to recheck but that combo may run for an additional 12.5 seconds at the end because the duty cycle will activate the output and influence the start/stop times. I'll check into that.

I'm typing this on my way to work but I'll re-read your post and see if I missed anything.
 
Last edited:
  • Like
Reactions: WillFord384
Ya I'll have to dive in tonight and set some limits on the duty cycle and pulse. It needs to be restricted within the interval duration times. I'll work on it.
 
LainIsLain said:
:love: Finally able to sit down for the evening. A fresh batch for ABU Space in the mail and some bomb fried rice from my favorite Chinese food truck with a little spicy sausage for good measure! LOL

View attachment 54395View attachment 54396

I'll spend a few minutes writing up a better description of the project. Your comments about the flow regulation are important @Gatorq2. The way I see it there are a few different design paths here with varying levels of technical approach as well as cost. I'll do my best and write up what I think the different paths are. For those interested I'm going to make it an update to the initial blog post so check there and I'll start that in a few minutes. Food time!!
I don't know which looks better, your delivery or dinner! I'm drooling! 😋
 
  • Haha
Reactions: LainIsLain
LainIsLain said:
Swap line 416 and 421. HIGH to LOW and LOW to HIGH.
Hi that worked, but also needed to adjust line 236 (BedWetter 0.2.51) from
digitalWrite(RelayPin, HIGH);
to
digitalWrite(RelayPin, LOW);

(otherwise the Relay is On/High when starting the program)
Correct?
 
  • Like
Reactions: LainIsLain
LainIsLain said:
If you leave the WET CHANCE option 0 that is effectively 100%. I have most of the variables roll over at 99 back to 0 to make things easier. I couldn't see a reason for the need to set a 0 chance of wetting so if the chance is 0 then the program ignores that setting and the chance is effectively 100%.
Clear to me now, perfect and understood.

LainIsLain said:
The WET CHANCE is calculated one time at the beginning of the run. Meaning if you have 50% entered there is a 50% chance the output will be activated at all during the night. I hope that's the behavior you wanted. If you'd rather have a chance weeting for each event then I can change that.
Also 100% correct as it is now, i wanted to be calculated one time at the beginning of the run.
And that is how it works now. For me 100% Ok and happy with this Wet Chance calculation.
 
johnzld said:
Hi that worked, but also needed to adjust line 236 (BedWetter 0.2.51) from
digitalWrite(RelayPin, HIGH);
to
digitalWrite(RelayPin, LOW);

(otherwise the Relay is On/High when starting the program)
Correct?
Yes your right. It might be important to also add an option in the CONTROL menu to invert the output behavior.

I'm testing on a relay module board. Some may want to control a relay in a different configuration.

I'm going to add some limits on the duty cycle. So you can set an interval duration but there needs to be a restriction so you can't set a duty pulse that's larger than the duration. I think that will clear things up.

Going to work on that when I get off work.
 
Last edited:
LainIsLain said:
Ok small update.

Added LCD backlight control under Control menu. You must manually change "int LCDBackLight = 0;" to the correct pin. In my case it's 10. Use at your own risk but it should be fine for most.

Changed relay behavior to be inverted!!!
Hi, can yoy say what behaviour your relay had?
Your relay was indeed activated(powerline/current on) OR is it that you used maybe the Normal-Open contacts op the relay?
Asking this because from out the first version my relay was acting as expected.
Outpin pin low= relay power led of
Outpin pin high= relay power led on
(not talking about the switch contacts of the relay itself that controlled the solenoid/pump but the power to the relay)
 
LainIsLain said:
Your results for v0.2.51 are probably correct.
Ok,let's test in a more simple set-up then...back to basics ;-)

LainIsLain said:
One thing I see is you have the duty pulse at 25, duty cycle 50%, interval duration 30, and interval 30.
So the program is dividing 1 hours by 30. So that's 1 activation every 2 minutes with duration of 30 seconds. During that interval the duty pulse is 50% of 25 sec. So for each interval the output will activate for 12.5 seconds then turn off for 12.5 seconds. This is a very long duty pulse time! The same effect would be if the interval duration was set to 13 seconds and the duty cycle and pulse were left 0.

You have chosen a very long duty pulse time. I'll have to recheck but that combo may run for an additional 12.5 seconds at the end because the duty cycle will activate the output and influence the start/stop times. I'll check into that.

I'm typing this on my way to work but I'll re-read your post and see if I missed anything.

So back to basics....will try to set-up version 0.2.51 as to be working as version 0.2.2

Options Set:
Sleep Time: 1h
Delay: 1m

Wet Change: 0
Wet Interval: 30
Interval Dus/s: 30

Prime: OFF
Output Pin: 3
Duty Cycle %: 0
Duty Pulse: 0


So with your explanation above would give:
- 100% change of wetting events
- 1 activation every 2 minutes with duration of 30 seconds
Correct?

The result:

Test- Output Pin gets activated(with above settings) on the count of:
(61 on, 91 off, 95 on, still on at 330..
tested 3 times....same result every time.

Can you reproduce/test this on your set-up?
 
I'm using this board.


The board had an LED that lights when the relay is active.

The LED/Relay was active when the Arduino pin was LOW and inactive when HIGH. It's a little counter intuitive if you set the pin HIGH you'd expect the relay to be "ON" but there is a relay driver circuit and it need to be LOW to drive the relay "ON".

Like I said I can add a way to invert the output behavior. That might make it easier for others to drive different types of relay configurations.
 
Last edited:
johnzld said:
Ok,let's test in a more simple set-up then...back to basics ;-)



So back to basics....will try to set-up version 0.2.51 as to be working as version 0.2.2

Options Set:
Sleep Time: 1h
Delay: 1m

Wet Change: 0
Wet Interval: 30
Interval Dus/s: 30

Prime: OFF
Output Pin: 3
Duty Cycle %: 0
Duty Pulse: 0

So with your explanation above would give:
- 100% change of wetting events
- 1 activation every 2 minutes with duration of 30 seconds
Correct?

The result:

Test- Output Pin gets activated(with above settings) on the count of:
(61 on, 91 off, 95 on, still on at 330..
tested 3 times....same result every time.

Can you reproduce/test this on your set-up?
I promise I'll check that when I get home. I'm still at work. 😜
 
  • Like
Reactions: johnzld
I'm sorry it's not working right. I should have let it run longer on my setup to make sure the behavior matched what I expected. I'll fix it.
 
LainIsLain said:
I'm sorry it's not working right. I should have let it run longer on my setup to make sure the behavior matched what I expected. I'll fix it.
No problem!
I like to test it, and be more then happy to help you with that.
If needed, just give me instruction what or how to test, so you have multiple test-results of multiple persons.

Btw: Any other members building and testing the set-up and software that is LainIsLain working on so good and hard?
Not seeing test-results of others... ;-)
 
  • Like
Reactions: LainIsLain
v0.2.52 up!

Ok I think I figured it out. The math I was doing to derive the intervals was wrong for the none random portion. It's fixed and should preform as intended. If you have the serial monitor active while pressing the select button for a "new" run. The serial terminal will print all the stored interval times. This will work for the random values also since there stored in the same array and are generated once at the beginning of a "new" run.

I limited the DUTY PULSE to be no bigger than the WET INTERVAL so they can't over lap and influence the start/stop times.
I also added a control menu item call "OutPutInvert". This will invert the output pin behavior. But please note if the setting is changed you should power cycle or push the reset on the Arduino!

Just a note here. The duty pulse and cycle are intended for "chopping" the output inside the duration time. Lets say you have 10/sec durations and 10/sec duty pulse with 50% cycle. This is the same output time as a 5/sec duration with no duty cycle active. I assumed you wanted the duty pulse and cycle to have short chops inside the duration. Like a 10/sec duration with 1/sec duty pulse and 20% cycle. This gives a chopping effect of the output. You mentioned this would be used as a kind of flow rate adjustment. Just remember if you are inputting very high duty pulse times your encompassing a greater amount of time inside the duration time. You may want to just leave the duty pulse and cycle at 0 and decrease the duration time to adjust the total flow amount.

I hope that makes sense. I did mention in another post that the duty cycle approach to flow regulation might be a bad idea. If you truly find it useful I won't remove it though. Like I said eventually the fine control of PWM over a pump will give much better flow control. Not only of total liquid but also total liquid over time. But I also recognize that this unit should fit the greatest number of scenarios possible.

Also another important note!!!!!! The values held in the EEPROM may change locations between versions. So It might be a good idea after loading a different version to also go to the RESET menu and do a wipe and then changing the settings you want. If this is not done and value locations change, the output or timing behavior may be unpredictable!! If you do this remember to also change to the appropriate relay output pin and change the newly added "OutPutInvert" setting then reset the Arduino.

I ran short test and watched for the output to match the stored interval values and it preformed out to about 10mins so I'll assume that's working now. Message back if something weird happens!

Heading to bed now!😌
 
  • Like
Reactions: johnzld and WillFord384
Just realized that if an initial delay is added it will shift the first interval but not effect the others. I need to change it so the initial delay shifts all the intervals. I'll do that tomorrow.
 
Last edited:
Back
Top