Notifications
Clear all
Search result for: WA 0821 1305 0400 [[Adefa]] Pusat Penjualan Geogrid Stabilisasi Lereng Heavy Duty Tabanan Bali
Page 2 / 2
Prev
| # | Post Title | Result Info | Date | User | Forum |
| Answer to: Best microcontroller or SBC for robotics? | 4 Relevance | 11 months ago | nathan | Theoretical questions | |
| If your robot needs both real-time motor control and higher-level processing (like computer vision or LIDAR), I’d recommend a hybrid setup. Use a Teensy 4.1 (or an STM32 if you're comfortable with it) to handle motor control, encoders, and IMU. Teensy is Arduino-compatible but much faster — 600 MHz and great real-time performance. Pair it with a Jetson Nano (or Raspberry Pi if you're not doing Heavy vision tasks) for computer vision, path planning, and data logging. Jetson Nano has GPU support and is great for running lightweight AI models or OpenCV. This combo gives you real-time performance where it matters and the flexibility of Linux for everything else. Communicate between the two using UART, I2C, or CAN depending on your latency needs. We've had good success with this kind of architecture in robotics projects using ROS. If you're using ROS2, check out micro-ROS for STM32 or rosserial for Teensy. Let me know if you need example setups or wiring tips. | |||||
| Answer to: Raspberry Pi OS vs Ubuntu vs DietPi — Which one is better? | 4 Relevance | 11 months ago | Dinesh bhardwaj | RPi Pico | |
| I’ve tested all three — Raspberry Pi OS, Ubuntu, and DietPi — and honestly, each one has its strengths depending on what you’re trying to do. If you're using a lower-end model like the Pi 3 or Zero, DietPi is a beast in terms of performance. It's super lightweight and boots fast, with very minimal background processes. Great for headless or server-style setups. Raspberry Pi OS is the most balanced in my opinion. It’s stable, well-supported, and has excellent compatibility with GPIO, camera modules, and most accessories. Plus, it’s officially maintained by the Pi Foundation, so updates and long-term support are pretty solid. Ubuntu (especially Server) is decent, but I’ve found it to be a bit heavier on Pi 3 and not ideal for Zero. It works better on Pi 4, and is nice if you're already used to Ubuntu on desktops or other servers. That said, sometimes peripherals or GPIO need extra tweaks to work smoothly. In terms of ease of use — Pi OS with Desktop is very beginner-friendly. DietPi is command-line based but has a great first-boot installer that lets you choose only what you need, so it’s pretty efficient. Ubuntu is more for those who are already comfortable with Linux. For community and support, Pi OS is the winner. Tons of tutorials, help forums, and guides tailored specifically to the Pi. DietPi and Ubuntu both have good communities too, but they’re a bit more general. My personal picks: For simple or GPIO-heavy projects → Raspberry Pi OS For lightweight, headless, or server projects → DietPi For more advanced server use on Pi 4 → Ubuntu Server Hope that helps — happy to share more if you’ve got a specific use case in mind! | |||||
| Answer to: What’s the real impact of a broken neutral in a 3-phase 4-wire system? | 4 Relevance | 11 months ago | LogicLab | Theoretical questions | |
| Yeah, losing the neutral in a 3-phase 4-wire system can cause major issues, especially if the loads aren’t balanced (which they usually aren't in real-world setups like homes or small businesses). What actually happens is this: the neutral point “floats” because there's no solid reference anymore. So instead of each phase staying around 230V, the voltages start to shift depending on the loads on each phase. Light load = lower voltage, Heavy load = higher voltage. In the worst cases, one phase might go up to nearly 400V—way more than your appliances are built for. As a result, you'll see major voltage fluctuations in your supply. There are protection relays and devices that can catch this (like a phase failure relay or neutral monitoring), but not every system has them—especially older setups. In short: broken neutral = unpredictable and often destructive voltage swings. A real pain to troubleshoot if you don’t catch it quickly. | |||||
| Answer to: What are your opinions about Teensy boards? | 4 Relevance | 1 year ago | Admin | Arduino | |
| Teensy boards are incredible, especially for projects that need more power or advanced features. Here’s how they compare to Arduino: Performance: Teensy boards (like Teensy 4.1) have significantly more processing power. For example, Teensy 4.1 runs at 600 MHz, compared to Arduino Uno’s 16 MHz. They’re great for applications like real-time audio processing, high-speed data acquisition, or complex robotics. Features: Teensy supports USB HID devices out of the box, so you can create custom keyboards, MIDI controllers, or gamepads. It has more RAM, Flash memory, and better peripherals compared to most Arduino boards. Ease of Use: Teensy integrates well with the Arduino IDE via the Teensyduino plugin, so transitioning from Arduino is pretty seamless. However, it does require a slightly steeper learning curve if you’re using its advanced features. If you’re working on high-performance or resource-heavy projects, Teensy is absolutely worth it | |||||
| Answer to: Effect of PWM frequency on motors and LEDs | 3 Relevance | 9 months ago | nathan | Theoretical questions | |
| PWM frequency doesn’t change the basic control of speed or brightness (that’s handled by Duty cycle), but it does affect how smooth and practical the control feels. For DC motors, too low a frequency can cause audible whining and jerky torque, while using a frequency in the 2–20 kHz range keeps operation smoother and moves the noise above the human hearing range. Going too high can reduce efficiency due to increased switching losses. For LEDs, low frequencies below ~100 Hz cause visible flicker, which is unpleasant and can be noticeable on cameras as well. Frequencies in the 200–500 Hz range reduce flicker significantly, but for professional lighting or display applications, 1 kHz and above is generally preferred to ensure flicker-free performance. | |||||
| Answer to: What exactly is PWM resolution ? | 3 Relevance | 2 years ago | catElectronics | Hardware/Schematic | |
| To put this PWM resolution concept into a practical context: If you’re dimming an LED with an Arduino UNO’s 8-bit PWM, you might see noticeable brightness steps when changing the Duty cycle. This is because each step is about 0.4% of the total brightness. With the ESP32’s 16-bit PWM, each step is only 0.0015%, so the LED brightness change is much smoother and almost imperceptible. This is crucial if you’re working on projects that require precise control, like mood lighting or audio signal modulation. But keep in mind, that the lower frequency at higher resolutions might introduce visible flicker in LEDs, so you’ll need to find a balance between resolution and frequency depending on your application. | |||||
| Answer to: analogWrite() Used on Digital Pins Instead of Analog Pins? | 3 Relevance | 2 years ago | catElectronics | Programming | |
| To expand on what @ankunegi said, here’s a simple example of how analogWrite() works on a PWM pin in practice: void setup() { pinMode(9, OUTPUT); // Pin 9 supports PWM } void loop() { analogWrite(9, 128); // 50% Duty cycle (128 out of 255) } This will make an LED connected to pin 9 glow at half brightness because the average voltage is 2.5V (on a 5V Arduino). If you try this on an analog pin like A0, it won’t work because analog pins are meant for input, not output. It’s just a quirk of how Arduino names function. Once you get used to it, it’s not a big deal. | |||||
| RE: What exactly is PWM resolution ? | 3 Relevance | 2 years ago | Admin | Hardware/Schematic | |
| The microcontroller uses a timer to generate the PWM signal. The timer counts up from 0 to a maximum value. When it reaches the maximum, it resets to 0 and starts counting again. The Duty cycle is determined by the value at which the timer output switches from low to high. For 8-bit resolution (UNO): The timer counts from 0 to 255. To achieve the maximum PWM frequency, the timer should overflow as quickly as possible. So, the maximum PWM frequency is the clock frequency divided by the maximum count: 16 MHz / 256 = 62.5 kHz. For 16-bit resolution (ESP32): The timer counts from 0 to 65,535. Using the same logic, the maximum PWM frequency is 16 MHz / 65,536 = 244 Hz. In essence, higher resolution requires the timer to count to a larger number before overflowing, which takes more time. This directly limits the maximum possible PWM frequency. | |||||
| Answer to: analogWrite() Used on Digital Pins Instead of Analog Pins? | 3 Relevance | 2 years ago | Admin | Programming | |
| ... the digital pins ON and OFF at a very high frequency creating a dummy analog signal. And there are 6 digital pins on UNO that supports this behavior- with a "~" symbol next to them (like 3, 5, 6, 9, 10, 11) When you use analogWrite(pin, value), you're controlling the Duty cycle of the PWM signal A value of 0 means the pin is off all the time. A value of 255 means the pin is on all the time. Values in between control how long the pin stays on during each cycle, effectively simulating an analog voltage between 0 and 5V. So analogWrite function has nothing ... | |||||
Page 2 / 2
Prev
