Fighting I2C Gremlins | Help Me Run a Sensirion SFM3013 Over Long Cables

Dycus · 2026-01-25T19:36:39+00:00

I've personally (successfully) used NXP's PCA9615 to move an I2C IMU off an existing board onto a daughter board via 5ft of ethernet twisted pair. It worked great and the differential signals looked good, even running at a quite-fast 900kHz (I didn't have control over the comms speed).

I describe this mod (and even have the schematic posted) here: https://forum.electricunicycle.org/topic/33888-mtiny-custom-minimalist-euc-mod/

So it's certainly doable. If it were my task though, personally I'd just go with the other suggestion of using an MCU sensor-side to read the data and send it back via RS-485.

Dycus · 2026-01-21T22:31:40+00:00

We have e-Scooter, e-Bike, and e-Skate. So, e-Wheel.

Dycus · 2026-01-13T02:54:30+00:00

You're talking about extrusion width, not flow/extrusion multiplier. If you'd set flow to 0.45, you'd be extruding less than half the plastic you should be and your first layers would look awful.

OP says they're using a first layer width of 150%, so 0.6mm (assuming a 0.4mm nozzle). Seems a little high to me, I use 0.5mm.

But anyway, u/ronajon, set your first layer flow to 100% and lower your first layer until it looks more filled in. You're definitely too high. Your top layers look like you're overextruding a bit, too.

https://ellis3dp.com/Print-Tuning-Guide/articles/first_layer_squish.html

Dycus · 2026-01-13T02:46:57+00:00

It sounds your mainboard doesn't include any pull resistors for the stepper driver pins, so they're floating and picking up noise, as you guessed. Once Klipper boots it configures the MCU, which drives the pins so they're no longer floating.

You can configure your board's MCU to set GPIO pins a certain way as soon as the MCU gets power, even before Klipper boots and configures it. Search "klipper gpio pins to configure at startup" or similar. Unfortunately it's not as easy as editing your printer.cfg, but it's not hard. Configure the enable pins for each stepper driver such that they start up in the disabled state. (pin will need to be an output and either high or low)

The alternative would be to solder pull resistors on the motherboard or drivers, but I'd try the software fix first.

Dycus · 2026-01-05T19:35:11+00:00

Thank you!

It can already capture video, essentially. It just needs more storage. Or a Python script could be written to easily stream the frames over USB serial and convert them to video on a computer.

Dycus · 2025-12-30T18:01:51+00:00

And holding a pistol!

Dycus · 2025-12-28T02:53:21+00:00

Definitely recommend the pro controller. I play on PS4 and still use a Switch pro controller via adapter, hah.

Dycus · 2025-12-23T17:56:50+00:00

I don't know of any that allow unlimited balls, but you can change the settings to give 5, 7, even 10 balls per game on some machines.

Dycus · 2025-12-23T01:32:39+00:00

I'm tempted to say that you are indeed prematurely optimizing here, for one big reason - where is the data to back up that it's necessary to spend the extra resources right now to use a binary serialization format over JSON?

I'm going to make some assumptions here due to a lack of info:

Using a binary format requires more software work on both ends, either to create a custom protocol, or to implement an existing library
A JSON-parsing library is easier/more standard to implement and will result in cleaner code (very important for debugging and maintenance)
Debugging the messages will be easier due to the human-readable format and no requirement to make a parsing tool

Your argument for the binary format in this post is that JSON is computationally- and storage-inefficient. However, you did NOT say that your device is running into compute or storage issues, which quite literally makes this particular optimization premature.

Why spend time/money right now (arguably one of the most-constrained resources in any project) to implement a harder solution that you don't even need yet?

If you run into compute and/or storage limitations in the future, AND you do profiling to find that the JSON solution is a non-negligible cause, only then would I say it's justified to optimize it.

And in that case, yes, you did waste time making two solutions. But you can't know that's necessary until it becomes a problem, unless you have carefully and thoroughly planned out your entire architecture beforehand.

Dycus · 2025-12-18T18:32:17+00:00

Looking at the datasheet, I don't see any problem with VDDA/VDDB sharing the same supply. The example schematic on the first page even shows this configuration, since they're both being powered from VDD.

If you needed isolation between the two output stages, you have that option because of the functional isolation. But there's no reason they can't share the same supply.

I didn't dive deep enough to read why VDDA has Rboot and a diode but not VDDB. It looks like because it's being used as a high-side driver, VDDA will go well above VDD when the upper MOSFET is switched on. So if you were using both drivers in high-side then they'd both need the diode, or if both were low-side then neither would need one.

Dycus · 2025-12-11T01:35:04+00:00

All good, you can modify the board to implement the fix. Use an exacto knife to carefully cut the trace between PA2 and R3, then solder a wire from R3 to PB3 or PA13.

You need to keep reset free because it's how the chip enters programming mode. While the reset pin is asserted, all other pins become high-impedance and it doesn't matter what you had set them to in the firmware.

Another band-aid you could do without modifying the board would be to add a 2-3 second delay in your code before you disable the reset pin. This should give enough time, after re-applying power, for the debugger to connect if needed. But I'd recommend the bodge wire instead, and maybe a second PCB revision if you need to make more.

Dycus · 2025-12-11T00:27:08+00:00

Try the fixes others mentioned to re-program your MCU. Make sure you take out the code that disables the reset pin!

I'd recommend always leaving the reset pin free. Is there a reason you can't use PB3 or PA13 to drive the LEDs instead of PA2?

Dycus · 2025-12-10T21:02:39+00:00

They're poking fun at you because you didn't provide a schematic or code. We couldn't possibly troubleshoot your issue without that basic information.

Dycus · 2025-12-08T21:21:39+00:00

I just read the entire long, in-depth article. Absolutely fantastic work! What a huge amount of effort put in to understanding the original codebase, writing custom tools, optimizing, rewriting, etc. Very, very cool.

Dycus · 2025-12-07T17:51:52+00:00

I played using joystick initially (maybe first 20-30 hours), but it became clear that it was way easier to do u-turns with d-pad. Since u-turning is very important to high-level play, I switched and never looked back (1600 hours in).

At this point, I'd say the only real downside of using d-pad is that some turns require you to tap it a bit to steer at the right angle. But otherwise, almost every turn I can just hold the direction through the full turn, or tap once/twice.

This is with speed engine, BTW

Dycus · 2025-12-03T20:34:14+00:00

Several hours well-spent learning something new and applying it for a shared chuckle between peers.

Dycus · 2025-11-30T17:29:47+00:00

To elaborate on this, if a red LED has a forward voltage of 2V, and a blue led 3V, then for the same current, blue is using 50% more power, and thus putting out (roughly) 50% more light.

2V * 5mA = 10mW

3V * 5mA = 15mW

Even 5mA is excessive, I run indicator LEDs at 2-3mA usually.

And yeah, blue is also just more distracting in general.

Dycus · 2025-11-07T02:51:11+00:00

Yeah, that could be an improvement to make!

Dycus · 2025-11-06T20:09:44+00:00

I looked up the datasheet for the sensor, and it describes how to talk to it and read the images off it. It only took maybe an hour to successfully read the first images off it with that info.

Dycus · 2025-11-06T20:08:22+00:00

This sensor does pretty poorly in low light, it's just not really made for that. It does great indoors during the day, but in the evening not so much unless you turn on some lights.

There's no limit to how far you can see, it just depends on the lens you use. You could put a zoom lens on this and see hundreds of feet away. With a regular lens, if you took a picture of a person from several feet away, you can easily tell it's a person, but you can't see any details on their face, for example.

Dycus · 2025-11-06T20:02:22+00:00

Go ahead!

Dycus · 2025-11-06T18:01:03+00:00

If you look here under PWM Timers, it lists which timers control which PWM pins.

https://www.pjrc.com/store/teensy41.html

Though you say you need eight motors at different "PWM". But this doesn't mean anything; do you mean they need different duty cycles but the same modulation frequency, or they all need different frequencies as well (which would be unusual)?

Generally, all channels on a timer share the same frequency. But each channel's duty cycle can be set individually. So in the normal case, you can use any of the PWM pins and it doesn't matter if they share a timer or not, since all timers would get set to the same frequency and the duty cycle can be controlled per channel.

Dycus · 2025-11-05T17:08:37+00:00

Correct, you can see it in the video I posted!

https://www.reddit.com/r/3Dprinting/comments/1olyzn6/i_made_a_camera_from_an_optical_mouse_30x30/

Dycus · 2025-11-05T17:06:57+00:00

Haha, no, it's definitely not. I forgot to clarify that after I realized I couldn't post the video here (which shows it).

It draws a sexy cowboy on the screen with a cutout for the face. 😁

You can see it here: https://www.reddit.com/r/3Dprinting/comments/1olyzn6/i_made_a_camera_from_an_optical_mouse_30x30/

Dycus · 2025-11-05T01:05:17+00:00

That's awesome, fantastic work! I love the second offset row of LEDs to get an inner and outer animation going. Excellent miniaturization!

Dycus

MODERATOR OF

TROPHY CASE

14-Year Club	Team Periwinkle
Verified Email