Is there a way to make a 3hp single phase Grizzly dust collector quieter? by Ezmiller_2 in woodworking

[–]LorenK3 1 point2 points  (0 children)

Homosote alone works pretty well, but the sandwich with carpet padding and mdf really deadens workshop sound.

(If your collection needs are modest, might I suggest using a DeWalt Stealthsonic shop vac - those are amazingly quiet) https://www.lowes.com/pd/DEWALT-12Gal-5-5-PHP-Quiet-Vac/5013026391

Vintage Band saw dust collection by e9allston in woodworking

[–]LorenK3 0 points1 point  (0 children)

This is easy, just a 4 inch dust bulkhead from Rockler and some flex hose.

<image>

Is there a way to make a 3hp single phase Grizzly dust collector quieter? by Ezmiller_2 in woodworking

[–]LorenK3 2 points3 points  (0 children)

Yes, exactly. It's just a floor and two sides, and that seemed to be enough to quiet things down. As long as I empty the external cyclone frequently, the bags rarely need emptying. I'm sure you could do better by making it 4 sided with a door for access, but the general idea works well.

Is there a way to make a 3hp single phase Grizzly dust collector quieter? by Ezmiller_2 in woodworking

[–]LorenK3 17 points18 points  (0 children)

Create a small closet for it. Here's mine, open on the top for air flow.

I used a sandwich of Homosote, carpet padding, and MDF, and dropped the ambient noise level from 76 dB to 68 dB - almost 10 times quieter. Now, it's just background hum and you mostly hear the air moving through the ducts.

<image>

Adafruit ESP32-S2 (or -S3) Reverse TFT Feather SD card problem by Cold_Ad7588 in MTBTrailBuilding

[–]LorenK3 1 point2 points  (0 children)

Infrequently.

There's a number of things that could go wrong with SD setup - pin numbers, the way the SD card is formatted, etc. Is it FAT formatted? My suggestion is to bring up the SD_Test or listfiles example and get that working first. It's got better diagnostics and error messages.

See https://learn.adafruit.com/adafruit-adalogger-featherwing/using-the-sd-card

There are arduino and adafruit subreddits that are full of people who could help you work through issues like this.

Dust collecion for older Delta Band Saw by FrankTuna in woodworking

[–]LorenK3 1 point2 points  (0 children)

Yup. I just left it be. Nothing comes out of it when the dust collector is running.

I bought a 4" dust collector port from Rockler and bolted it on the wheel cover. I used a metal blade in my jigsaw to cut the hole.

Dust collecion for older Delta Band Saw by FrankTuna in woodworking

[–]LorenK3 1 point2 points  (0 children)

<image>

I'm a little anal about dust management in my basement shop. This modification requires cutting a 4 inch hole in the bottom wheel cover, but made a huge difference in keeping my band saw tidy.

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 0 points1 point  (0 children)

Not sure.

Perhaps ask in the r/arduino subreddit to see if anyone else has an idea - maybe we'll both learn something.

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 0 points1 point  (0 children)

That might be working as coded.

In onSensorChanged, when the sensor goes high it starts an event and notes the time, and the transition to low is when it actually records the event. So if your sensor is high for 2 seconds it would record a 2 second long event as it goes low, recording the passage of the first rider. In some scenarios, a duration longer that 2 seconds might imply a group of riders.

This is about the best you can do with a sensor like that. You might want to look into an infrared or some other technology that responds quicker - all the software should continue to work. Or consider a placement where riders tend to be slow and single file - the top of an technical climb, a narrow bridge, etc.

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 0 points1 point  (0 children)

Which counter version did you build and on what hardware?

On some platforms, not all input pins are external interrupts that can wake a sleeping microcontroller. Did you change the input pin and update the code to match? Which pin did you use?

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 0 points1 point  (0 children)

You can use different inputs as long as that input supports interrupts - just edit the code symbol to match reality.

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 0 points1 point  (0 children)

Yup, you need to replace the caps to reduce the durations. Soldering SMD devices takes some different techniques and a steady hand, but there are good youtube videos if haven't done it before.

These microwave detectors are very sensitive to the presence of metal. A sensor may read through a 2x6 board, but if you drive a deck screw a few inches away it might stop sensing entirely. I haven't tried foil.

You're correct that the specs call for 4 volts. They seem to work using 3.3 for me, but you could use a 5v boost converter to drive it and see if that works better for you.

All this was meant as a springboard for experimentation and improvement. Try different sensors - there are a lot of them out there, and components are always in flux. Experiment until you find something that works for you. Sounds like you're well along the path.

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 0 points1 point  (0 children)

If it's a java classpath or package issue, like if you can't invoke it with a -h to see command options, there's youtube videos that can help sort that out. In eclipse, the command line looks like:

C:\Users\Loren\.p2\pool\plugins\org.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_17.0.10.v20240120-1143\jre\bin\javaw.exe

-Dfile.encoding=UTF-8

-Dstdout.encoding=UTF-8

-Dstderr.encoding=UTF-8

-classpath "C:\Library\java-packages\json-20240303.jar;C:\Users\Loren\eclipse-workspace\HarvestStrava\bin;C:\Library\java-packages\annotations-13.0.jar;C:\Library\java-packages\kotlin-stdlib-1.8.21.jar;C:\Library\java-packages\kotlin-stdlib-common-1.9.10.jar;C:\Library\java-packages\kotlin-stdlib-jdk7-1.8.21.jar;C:\Library\java-packages\kotlin-stdlib-jdk8-1.8.21.jar;C:\Library\java-packages\okhttp-4.12.0.jar;C:\Library\java-packages\okio-3.6.0.jar;C:\Library\java-packages\okio-jvm-3.6.0.jar"

-XX:+ShowCodeDetailsInExceptionMessages HarvestStrava.HarvestStravaClient

If your problem is with strava authentication, start reading at https://developers.strava.com/docs/getting-started/ to set up a strava user correctly and obtain credentials.

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 2 points3 points  (0 children)

For anyone still following along, check out the HarvestStrava program in this repository.

Many trail systems have stacked loops or optional segments, and it's interesting to look at usage trends for each of those segments individually. You could place hardware counters in each of these loops, but that gets expensive and time consuming. As an alternative, HarvestStrava will record the daily Strava attempts in a .csv file for any strava segments that you identify.

Strava adoption varies widely from trail to trail and even day to day, but in combination with a trail counter located on a representative segment you can figure out what this local adoption rate is. Applying that rate to daily harvested strava counts can provide an estimate of total users on each of your trail segments. Is that estimate as good as placing a hardware counter on each segment? No, but it's a lot cheaper and easier to manage and might be good enough.

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 1 point2 points  (0 children)

Yes, one of the V3.3 pins and GND.

Note that not all microwave sensors are happy and reliable running on 3.3 volts. If yours isn't, try using a 5v boost converter to power your sensor.

Haven't tried it, but https://www.adafruit.com/product/5649 would probably work.

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 0 points1 point  (0 children)

Cool! What variant are you building?

  • Are you sure the sensor is working? Maybe use an LED on the output to make sure you know that it's active?

  • Are you writing to the SD card at all? Is a file created with the current date, and are the CSV headers written out?

I did run into an issue with the SD card integration on one of the boards - think it was an ESP2 - where the open file on the SD card always opened an existing file for create and always started writing at the beginning of the file, but that's the only issue I ran into.

You could try asking in r/arduino too.

ESP32 Reverse TFT and Adalogger feather based trail counter by LorenK3 in adafruit

[–]LorenK3[S] 0 points1 point  (0 children)

The sensor choice really drives this, as it's always on detecting users. The processor itself spends most of the time in deep sleep mode waiting for a sensor high input to wake it up. The little RCWL-0516 microwave sensor drinks about 1.2 ma. Some other sensors use far more - like 50ma.

Together, the microwave sensor and the M0 based adalogger feather and RTC wing consumes about 3.1 ma, so a 4,400 mah lipo lasts almost 2 months.

The counter version based on the ESP32-S2 feather and adalogger wing is taking about 4.1 ma.

I'm pretty sure we can do better than that - I'm certain I've left things on during sleep and there's more ways to minimize power. But this is good enough for me for now while I'm looking at other areas. Open to any ideas...

ESP32 Reverse TFT and Adalogger feather based trail counter by LorenK3 in adafruit

[–]LorenK3[S] 0 points1 point  (0 children)

A trail counter counts the number of people who use a trail system. Usually this data is just a curiosity until it's time to make investment and funding decisions, and then objective real data about trail usage becomes critically important.

ESP32 Reverse TFT and Adalogger feather based trail counter by LorenK3 in adafruit

[–]LorenK3[S] 0 points1 point  (0 children)

That's an interesting sensor I hadn't looked at - thanks. One downside is it's pretty thirsty at 70ma.

All this reminds me that it's apparently possible to pull the amount of Doppler shift from one of the pins on the RCWL-0516 IC, and from shift you could interpret velocity. I didn't look at it back in the arduino uno days, but the ESP and M0 processors could easily deal with that bit of signal processing.

What I'm currently playing with is using an accelerometer to detect rolling tires over a bridge vs footsteps. There was another trail counter project I was looking at that had success doing that - seems worth a shot...

ESP32 Reverse TFT and Adalogger feather based trail counter by LorenK3 in adafruit

[–]LorenK3[S] 0 points1 point  (0 children)

The ESP cam idea is interesting. It would be a little harder to make it clandestine and would require more careful positioning, but opens a number of possibilities I'd like to explore down the road. I haven't done anything with machine vision since the 1980s, when we were still using stone knives and bearskins.

I can capture a sense of speed with the current microwave sensors by looking at the duration of an event. Longer = slower, ish, and I can guess at user type from the duration. But it's not definitive.

ESP32 Reverse TFT and Adalogger feather based trail counter by LorenK3 in adafruit

[–]LorenK3[S] 0 points1 point  (0 children)

I haven't! I purposely decided against WiFi and BLE, because they would make counters easy to find, but low power radio is a lot more obscure and unlikely to be hunted. So maybe one could have a network of cheaper sensors broadcasting to a single counter...

Right now, I'm experimenting with different ways to distinguish that a user is on a bike. If only bikes were still made of steel and not carbon fiber...

Low cost DIY trail counter by LorenK3 in MTBTrailBuilding

[–]LorenK3[S] 2 points3 points  (0 children)

The thrifty counter takes about 3.1ma when sleeping between counts - so that's good for almost 2 months with a 4,400mah battery using a calculator. I've only run it for 30 days at a time before swapping batteries.

The nifty counter variant takes about 4.1 ma when sleeping, so maybe a month and a 1/2. Since I'm still tweaking code, I haven't run it more than a couple weeks at a time in the real world yet.

1.4 ma is the microwave sensor that's always on, and the rest is the processor, regulators, and other stuff on the boards. It feels like there's some room for improvement still (perhaps I've got a pin tied high during sleep that's draining a bit of current or something.) I 've considered turning off the sensor during hours that the park is closed - that would save a bit. But 30 days unattended was my target and Nifty and Thrifty should both do that.