It Feels Like
Tonight I hit COM Port 65Is the whatever always in the incorrect configuration for what you need?
Is the incorrect chuck on the lathe, the incorrect air fitting on the hose?
or do you just care when it's incorrect?
I developed a new technique
holding the solder in a fixed position
then moving a pre-fluxed board and component toward the solder
after heating the joint with a freshly tinned soldering iron.
Instead of using resisters to control the brightness of the LEDs,
I'm using PWM.
I'm giving the LEDs the full 3.3 Volts
but at a 50% duty cycle for the red,
and a 25% duty cycle for the green, led.
at a frequency of 5000Hz.
So I messed up and started to solder the jumper between VBUS and GND
which would have shorted the entire board, at 3.7 (nominal) Volts and at a sustained 10Amps.
I corrected that; and left solder at VBUS.
I'm thinking of logging a timestamp with button press to make sure that someone doesn't try to taint the data by pressing a button over and over again. I'll probably store a last_pressed time stamp and flag the data as it's being logged
I've probably already corrupted the file system.
Such a fragile file system...
I'm using CircuitPython for file system accessibility
the fragility of the file system is an issue.
Project costs are reasonable:
I switched to MicroPython
...and COM66
Data File:
I've updated the project costs
Yes, I really should have connected the positive battery terminal to the board
through a Schottky Diode to prevent back-feeding the battery
during data collection.
I'm using the jumper to enable the data logging mode,
and prevent writing to the file system when collecting data.
I used that data to drive adding code to turn off the status_led
one more change
BEFORE powering either the Red or GREEN LEDs
It is ill advised to leave Me and Well Enough alone.
Foreshadowing
The Schottky Diode thing got to me.
1N5817 installed
3D-Printed a mouthing bracket for it
I made one more code change:
time.sleep(0.05) #for debounce
increased to:
time.sleep(0.5) #for caution
Hackin' in the movies be like:
As Hatem says:
"Ready!"
Implemented
That is all.
Data File
datafile.csv
My thoughts are that this might equate to the percentage of usage of one fitting to another.
The reasoning would seem to be:
even if you could predict that a change would be statistically beneficial
don't change anything until you need to...
And of course I updated the code:
I think that there's a lot more to capture.
I really think that "percentage-of-the-time-use" may contribute to the outcome.
Establish extremes:
2 attachments, one is never used (still in the box), then only green button presses are possible; unless someone unhooks it.
The range of this experiment is … starting to lose myself here…
I do this stuff when I'm really high…
So, if we expect the true long-term outcome of the experiment to be 50-50, then any shift in the relative percentages of use of a particular attachment over another will skew the results….
A secondary log of green A fitting or B fitting and (/or?) Red A or B… not sure that one can't be extrapolated from the other.
When you open the shed, please:
If the Bot is off:
Make sure that the blue jumper bridges Pin2 (aka GPIO1) to ground.
Move the power switch (bottom right) to the right
All LEDs will illuminate for half a second.
The Status LED (next to the jumper) will flash every 100 times it checks the buttons. So about twice a second.
When you close the shed, please:
If the Bot is running:
- Pull the blue jumper - all LEDs will illuminate
- Reattach the blue jumper
- Turn the bot off
If the bot is running or not:
- lock up and go home.
This is Data Harvesting:
Anomaly
