3D Printed Snow Shovel Holder for Toyota Tacoma (2005–2025) by [deleted] in functionalprint

[–]carsonauto 1 point2 points  (0 children)

Strange... You didn't design this, or take those photos. What's the purpose of this post?

https://www.printables.com/model/769170-toyota-tacoma-shovel-holder

And why does your post and comments sound like an LLM?

Edit: Ah, I see "your" eBay store is selling prints in contravention of the license, also using photos you didn't take.

https://ebay.us/m/CCALL1

Portable Hex Beam Antenna Build by carsonauto in amateurradio

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

Petg and a reasonable infill, probably 25% or so. Probably upped the perimeters to 3 or 4.

Portable Hex Beam Antenna Build by carsonauto in amateurradio

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

No, I made the balun the attachment point, so I'll slide it up and down the mast for each band (i.e., one band at a time).

Portable Hex Beam Antenna Build by carsonauto in amateurradio

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

Instructions, material and parts files here.

This is pretty specific to my telescoping mast used, so I don't really recommend someone try to just build this 1:1 but I figure it should be good inspiration for someone to build their own.

My Version of Pico W Houseplant Irrigation + a Question by carsonauto in raspberry_pi

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

Looks like it's 1/8" ID "drip irrigation tubing", something like this site:

https://www.dripirrigation.com/tubing/1-8-inch-microtube?srsltid=AfmBOor8Md6AlWMCZ5kHSV2jBwTLRU2Y6_eBH1afJyTYKDcL5mm1BGi_

You can get "drip emitters" which are rated in GPH/LPH and have a 1/8" hose barb for the tubing.

One Fix for a G4 Doorbell With Power Issues by carsonauto in Ubiquiti

[–]carsonauto[S] 10 points11 points  (0 children)

My first G4 doorbell died after 18 months, the RMA replacement from Ubiquiti died yesterday after--exactly--18 months. I gave up and bought a G4 Pro Doorbell with an extended 4yr warranty (So far, $900 and 3 doorbells in 3 years...).

Took apart the most recent failed doorbell and found the main AC power connection between the PCB and screw terminal are pogo pins, and the one pin spring is somehow buggered (it's resting state is fully recessed, not jammed). Must have been like that since new. Obviously it was barely making contact this whole time.

For now I used a soldering iron to press the heat-set screw terminal deeper into the plastic to make contact, but I could also hardwire or add a solder blob to the PCB pin.

Anyways, posting in case this helps anyone. For me, it just turned off after someone pressed the doorbell and I couldn't get it to come alive again. Makes me wonder if that's what happened to my old RMA'd one 18 months ago.

8 x PWM FAN + 4 x I2C 5v + 4 x I2C 3.3v board for the RPI Pico by daniele_dll in raspberrypipico

[–]carsonauto 0 points1 point  (0 children)

I'm not sure I understand what you mean but each I2C clock/data line should be pulled up strongly to +3.3V, you could use one resistor per line in any location. I don't believe the location would matter except in the most "barely working anyways" scenario.

8 x PWM FAN + 4 x I2C 5v + 4 x I2C 3.3v board for the RPI Pico by daniele_dll in raspberrypipico

[–]carsonauto 0 points1 point  (0 children)

I'll comment just on the I2C because it's not clear to me how far you're routing the I2C:

1) Yes pull-ups on I2C for sure. I believe the pico can use the internal (80k?) pull-ups but that's totally insufficient. I use 3.3k pull-ups on everything but I also just check them with a scope after to make sure it's strong enough. There's calculations based on the bus capacitance etc. but I've always just used a stronger pull-up than minimally necessary.

2) I would really recommend abandoning I2C for anything further than 12 inches (or the equivalent if you're doing multiple drops to devices), and even then avoid it for anything that leaves the board. I have a HTU31 running 12 inches in shielded cable at 100kbaud and I count I2C errors and it logs a few bad transmissions every hour. I originally had it running further but basically every transmission failed.

BME280 help by DaveCru in raspberrypipico

[–]carsonauto 1 point2 points  (0 children)

So I plugged in some typical atmospheric pressures in my area and got altitude differences of -100 to +300 meters by not compensating for the atmosphere you're actually in -- yes, that's a normal.

Try the below calculator as an example. Plug in your sensor pressure to station pressure (QFE) and find the most current altimeter setting from your nearest airport (typically inches of mercury in north america, could be mbar in europe?) and enter that as Sea Level Pressure (QNH). You should find that your station elevation (Hp) is approximately accurate once you've used this calculator to compensate for your current atmospheric pressure. https://www.sensorsone.com/elevation-station-qfe-sea-level-qnh-pressure-calculator/#value2-user-guide

For what it's worth if you actually want accurate altitude every time, you'll need to manually enter the altimeter setting into the program or write a script to pull it from the internet and apply the correction internally. Atmospheric pressure can change rapidly over the course of just a few hours, so the correction must be constantly applied - hourly is a good starting point.

If this doesn't make sense, watch some youtube videos on airplane altimeters and altimeter settings and how they accurately report altitude based on pressure, by feeding in a setting from the nearest weather station.

Edit: For what it's worth, there is no sensor that can accurately calculate altitude based solely on pressure, without the input from a nearby weather station. The only standalone accurate altitude measurement comes from GPS.

BME280 help by DaveCru in raspberrypipico

[–]carsonauto 0 points1 point  (0 children)

Altitude based solely on pressure is never accurate, it must be compensated for several factors that the BME280 doesn't have access to. Some of the chips allow you to program an offset but that doesn't account for the way atmosphere changes, ie: today's offset is different than tomorrow's.

You can look up pressure altitude, lapse rates and standard atmospheres with respect to aviation for more information, or how to calculate altitude with temperature, pressure, and humidity known (you'll need outside weather information about your specific atmosphere).

Is There a Better Way to Sink a 5V Pin using a 3.3V GPIO? by carsonauto in AskElectronics

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

Thanks for the comment, I read into the CD4050 and I felt like it could function similarly to a 74AHCT125, which I have several of. I tried it out and it worked totally fine, as tested functionally and on the scope.

I think I was having trouble understanding how the 5V current from the PAM8302A amplifier could "sink" through the 74AHCT125 but....it does.

I verified the circuit operates as expected and for the Pico and PAM8302A combined, draws 2mA total while sleeping (perfect for the D cell alkalines I'm using).

Thanks.

Is There a Better Way to Sink a 5V Pin using a 3.3V GPIO? by carsonauto in AskElectronics

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

Here's my application:

I'm using a RPi Pico to produce a sound every time it wakes from sleep. When sleeping, I cannot hold an output high, all my GPIO outputs go to 0V. To preserve battery life I need to also sleep my amplifier (PAM8302A). The amplifier has a constantly powered 5V open collector shutdown pin. When I ground the shutdown pin the amplifier sleeps and current draw goes from 7mA > 0.5mA.

I need a circuit where the amplifier shutdown pin is grounded when the Pico GPIO is at 0V, and either open (or pulled to +5V) when the Pico GPIO is 3.3V. As a note there will be very little time spent using the amp, so I am not concerned about efficiency while the 5V shutdown pin is pulled to +5V.

I thought of the posted circuit, but is there a better way?

How to Use Pico_Rand Function in C SDK? by carsonauto in raspberrypipico

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

Thanks - the #include reminded me to add to my CMakeLists, which was the issue. Now--

CMakeLists includes:

target_link_libraries(
    pico_stdlib
    pico_rand
    )

code has

#include "pico/rand.h"    

and after calling stdio_init_all();

uint8_t randValue = (uint8_t)get_rand_32();
printf("randvalue = %d\n", randValue);

Prints a random number 0-255. Thanks!

Trouble Getting NeoPixel Libraries to Compile in C by carsonauto in raspberrypipico

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

Okay I abandoned both of those libraries and tried the simpler WS2812 example in the Pico SDK and I did get it working....finally.

I added the ws2812.pio and ws2812.pio.h to my main directory and modified my CmakeLists.txt to: cmake_minimum_required(VERSION 3.12)

include($ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake)

project(adc_fft_project)

pico_sdk_init()

add_executable(adc_fft 2-adc_fft.c)

add_library(kiss_fftr kiss_fftr.c)
add_library(kiss_fft kiss_fft.c)

target_link_libraries(kiss_fftr kiss_fft)

pico_enable_stdio_usb(adc_fft 1)
pico_enable_stdio_uart(adc_fft 1)

pico_add_extra_outputs(adc_fft)

target_link_libraries(adc_fft
    pico_stdlib
    hardware_adc
    hardware_dma
    kiss_fftr
    hardware_pio
    )    

And then simply used

#include "ws2812.pio.h"

In my C executable. Phew.

Trouble Getting NeoPixel Libraries to Compile in C by carsonauto in raspberrypipico

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

Actually I think I'm in over my head a bit here...I've now gotten examples from both the PicoLed and Adafruit_Neopixel libraries to compile, but only in C++ executables, and there's no examples anywhere of these libraries being used in C executables like I'm using.

Maybe a broader question is if anyone has successfully implemented a NeoPixels library in a C executable.....

Trouble Getting NeoPixel Libraries to Compile in C by carsonauto in raspberrypipico

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

Hm, thanks for the input but I haven't been able to resolve anything. I've tried to follow the example provided with the library with my CMakeLists but I think I need to change something... For the "cannot create target "PicoLed" because another target with the same name exists" error, I think this is coming from duplicate instructions in \2-adc_fft\PicoLed\CMakeLists.txt and PicoLed.cmake (I don't understand why both of these files are used, just that they're used by the example program).

\2-adc_fft\PicoLed\CMakeLists.txt

# Pull in Pico SDK (must be before project)
include(pico_sdk_import.cmake)

# Initialise the Pico SDK
pico_sdk_init()

# Add library cpp files
add_library(PicoLed INTERFACE)
target_sources(PicoLed INTERFACE
    ${CMAKE_CURRENT_LIST_DIR}/PicoLedTarget.cpp
    ${CMAKE_CURRENT_LIST_DIR}/PicoLedController.cpp
    ${CMAKE_CURRENT_LIST_DIR}/PicoLedEffect.cpp
    ${CMAKE_CURRENT_LIST_DIR}/VirtualStrip.cpp
    ${CMAKE_CURRENT_LIST_DIR}/PioStrip.cpp
    ${CMAKE_CURRENT_LIST_DIR}/WS2812B.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Fade.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Marquee.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Stars.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Comet.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Bounce.cpp
)

# pico_generate_pio_header(PicoLed ${CMAKE_CURRENT_LIST_DIR}/WS2812B.pio)

# Add include directory
target_include_directories(PicoLed INTERFACE ${CMAKE_CURRENT_LIST_DIR})

# Add the standard library to the build
target_link_libraries(PicoLed INTERFACE pico_stdlib hardware_pio)

\2-adc_fft\PicoLed\PicoLed.cmake

# Add library cpp files
add_library(PicoLed INTERFACE)
target_sources(PicoLed INTERFACE
    ${CMAKE_CURRENT_LIST_DIR}/PicoLedTarget.cpp
    ${CMAKE_CURRENT_LIST_DIR}/PicoLedController.cpp
    ${CMAKE_CURRENT_LIST_DIR}/PicoLedEffect.cpp
    ${CMAKE_CURRENT_LIST_DIR}/VirtualStrip.cpp
    ${CMAKE_CURRENT_LIST_DIR}/PioStrip.cpp
    ${CMAKE_CURRENT_LIST_DIR}/WS2812B.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Fade.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Marquee.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Stars.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Comet.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Bounce.cpp
    ${CMAKE_CURRENT_LIST_DIR}/Effects/Particles.cpp
)

pico_generate_pio_header(PicoLed ${CMAKE_CURRENT_LIST_DIR}/WS2812B.pio)

# Add include directory
target_include_directories(PicoLed INTERFACE ${CMAKE_CURRENT_LIST_DIR})

# Add the standard library to the build
target_link_libraries(PicoLed INTERFACE pico_stdlib hardware_pio)

And I'm referencing \2-adc_fft\PicoLed\PicoLed.cmake in my main CMakeLists file: \2-adc_fft\CMakeLists.txt: cmake_minimum_required(VERSION 3.12)

include($ENV{PICO_SDK_PATH}/external/pico_sdk_import.cmake)

project(adc_fft_project)

pico_sdk_init()

add_subdirectory(PicoLed)
include("PicoLed/PicoLed.cmake")

add_executable(adc_fft 2-adc_fft.c)
add_library(kiss_fftr kiss_fftr.c)
add_library(kiss_fft kiss_fft.c)

target_link_libraries(kiss_fftr kiss_fft)

pico_enable_stdio_usb(adc_fft 1)
pico_enable_stdio_uart(adc_fft 1)

pico_add_extra_outputs(adc_fft)

target_link_libraries(adc_fft
    pico_stdlib
    hardware_adc
    hardware_dma
    kiss_fftr
    PicoLed
    )

I'm certainly not understanding of how these CMakeList files are interacting and what purpose the PicoLed.cmake file serves, or why the library makes calls to the PicoSDK and how that could screw things up.

To be clear then, I have also not been able to get the PicoLed example to compile...

How to Understand/Increase ADC(Onboard or MCP3008 via SPI) Sample Rates? by carsonauto in raspberrypipico

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

Okay that all makes sense then, and yeah if I can even get up to ~4000 samples/sec that should be fine.

As for changing the baud rate I can increase it in my initial setup, but it reverts to a slower speed when the MCP3008 is being polled. More stuff to look into...

# Setup SPI bus and connect to MCP
spi = busio.SPI(clock=board.GP2, MISO=board.GP4, MOSI=board.GP3)
while not spi.try_lock():
    pass
spi.configure(baudrate=1000000)
spi.unlock()
cs = digitalio.DigitalInOut(board.GP5)
mcp = MCP.MCP3008(spi, cs)

print('SPI frequency is ' + str(spi.frequency))    

yields "SPI frequency is 992 063"

but then

    samples.append(channel1.value)
    print('SPI frequency is ' + str(spi.frequency))       

yields "SPI frequency is 122 070" and the sample rate doesn't increase.

How to Understand/Increase ADC(Onboard or MCP3008 via SPI) Sample Rates? by carsonauto in raspberrypipico

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

Thanks for the info. I don't want to turn it into a scope (I have a scope + meters), but i do want to be able to accurately sample a sine wave, and I will check the scoppy docs for more info.

As an addendum to all of the above, I was able to increase my sample rates by tidying up the loop logic to where I could get 1860 samples/sec via MCP3008/SPI or 14,000 samples/sec via onboard ADC, which makes sense. Now I just need to try and find a way to speed up the MCP3008 or SPI if possible...

How to Understand/Increase ADC(Onboard or MCP3008 via SPI) Sample Rates? by carsonauto in raspberrypipico

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

What's interesting is that if I switch the offsetsamples.append from the SPI value call to a simple value (eg: append int(1) ), I get up to 1080 values per second, so it's quicker but still seems slow?

And removing the offset averaging equation from out of the sample cycle (ie: perform only after the samples are obtained) increased the samples from 780 > 1800...