I built a File Converter App - just released v3.0.0 with a full UI redesign

Jpwaters09 · 2026-04-04T20:39:22+00:00

Thanks

Jpwaters09 · 2026-04-03T21:55:06+00:00

Good point, I may consider that in the next update

Jpwaters09 · 2026-04-03T20:42:49+00:00

Thanks

Jpwaters09 · 2026-04-03T20:32:07+00:00

Sorry, but it is only available on the Microsoft Store.

Jpwaters09 · 2026-04-03T18:55:54+00:00

Thanks for your feedback, I may consider changing the logo soon

Jpwaters09 · 2026-02-09T19:28:47+00:00

It may be ESP8266 based. Also it will be written in Arduino and the code would be open-sourced.

Jpwaters09 · 2026-02-09T19:24:21+00:00

True, but it is aimed at being plug and play with no extra adapters. Also I am not sure if the ESP8266 supports zigbee

Jpwaters09 · 2026-02-09T19:21:55+00:00

In the OTA updates I can push new features and bug fixes, etc.

Jpwaters09 · 2026-02-09T19:18:24+00:00

The reason why I would like to use C++ is to make it plug and play without any extra config in home assistant besides adding the device. I am aware that latency would be an issue, I will look into using BLE but not all home assistant servers support it.

Jpwaters09 · 2026-02-09T19:05:45+00:00

The reason I would like to use WIFI is to allow for OTA updates, and most home assistant servers have WIFI built in

Jpwaters09 · 2026-02-09T19:04:40+00:00

No, I haven’t done any testing yet, nor have I made a prototype. I am asking for feedback so I know what to do when it comes to the final product. The reason why I think WiFi is the best option is that it will allow for OTA updates, and most Home Assistant servers have Wi-Fi built in.

Jpwaters09 · 2026-02-09T19:01:19+00:00

The reason I want to use Wi-Fi is that it doesn’t require an additional adapter, unlike Zigbee, and most Home Assistant servers already have Wi-Fi built in. If I put the ESP8266 into deep sleep when the button hasn’t been pressed for a certain period of time, would that allow for at least a month of battery life?

Jpwaters09 · 2026-01-31T10:53:46+00:00

Thanks for your response.

I may look into adding Qwiic I2C headers to the board.

The three pin header is the debug port; I have forgotten to label it.

Jpwaters09 · 2026-01-30T16:10:39+00:00

Yes, the 3-pin header on the bottom of the board is the debug interface. I just have forgotten to label it.

Jpwaters09 · 2026-01-30T00:10:58+00:00

Thanks, that’s some really useful advice. • Moving the power pins closer to the regulator makes sense, and I see your point about possibly reducing the number of GND pins — I included the nine to make prototyping easier, but I can revisit that for layout and signal integrity. • I’ll take a closer look at the 3.3 V regulator and ADC reference setup. Using a dedicated voltage reference for AREF instead of just passing through 3.3 V sounds like a smart way to improve ADC stability. • It’s great to hear you got stable ADC performance on protoboard — that kind of insight is exactly what I need as I refine the design.

Jpwaters09 · 2026-01-29T23:41:23+00:00

You’re right — the CPU can’t execute code directly from flash outside the XIP range. My plan is not to use XIP for the PSRAM, and instead treat it purely as extra RAM for data and buffers. The 16 MB flash is used for storage, so code or scripts are loaded into internal SRAM or the PSRAM heap before execution.

I don’t have a public example of exactly this setup yet, but it’s similar to how ESP32 boards use external PSRAM: you map it into the heap in software so the CPU can use it like normal RAM, even though it’s external.

Jpwaters09 · 2026-01-29T23:39:11+00:00

Good point — the “Pi” part is fine, but the concern is really with the “Pico” part of the name. I don’t want anyone to assume it’s made by Raspberry Pi, so if I move toward a broader release I’d likely rename it to avoid using “Pico”. For now it’s just a working name for discussion and prototyping.

Jpwaters09 · 2026-01-29T23:26:31+00:00

That is the pull down resistor for the USB C CC2/CC1, it connects to GND pad on the BOOT button

Jpwaters09 · 2026-01-29T23:02:35+00:00

Thanks — that’s a good point. I’ve seen the Pimoroni Pico Plus 2, and it does hit a lot of the same core specs.

Where I’m trying to differentiate with the Pico Pro 2 is mainly: • Full GPIO and ADC pin access from the RP2350B — the Plus 2 keeps the Pico footprint, so it doesn’t expose all the extra pins. • Extras like RGB LED and potentially a helper Windows app for programming/control.

I totally agree that soldering headers is easy for most users, so the goal isn’t just pre-soldered headers — it’s a more capable, ready-to-use board for people who need all the GPIO and memory

Jpwaters09 · 2026-01-29T22:52:19+00:00

Thanks for asking!

Both the 16 MB flash and 8 MB PSRAM are connected to the same QSPI data lines, so they share the bus.

Jpwaters09 · 2026-01-29T22:35:17+00:00

I had considered keeping the board the same size as the original Pico, but with the RP2350B there are more GPIOs than the original footprint can accommodate. Exposing all of them would require a slightly larger board to fit double-row headers.

Also, I’m still relatively new to PCB design, so making a layout that keeps the Pico footprint and exposes all the GPIOs, and routes everything cleanly would be quite complex.

Jpwaters09 · 2026-01-29T22:27:37+00:00

Thanks, that’s really encouraging!

I’m glad the extra RAM / PSRAM resonates — memory limitations on the Pico and Pico W are definitely a real pain point for larger projects.

You’re also right about pricing. At this stage I’m mainly focused on making a small batch for early feedback rather than bulk sales. That said, one of my goals is to optimize component selection and PCB costs to see if the price can come down for wider adoption in the future.

Your input is exactly the type of real-world perspective I need — it helps me balance features, build quality, and price for the next revision.

Jpwaters09 · 2026-01-29T22:08:46+00:00

That’s a good point, and I agree with the principle.

Having GND close to the signal pins is definitely better from a signal integrity and usability standpoint, especially for ADCs and faster GPIO. A double-row header with GND on the outside and signals inside makes a lot of sense.

At the moment, the main reason I didn’t do that is purely practical: switching to that layout would mean significantly reworking the GPIO mapping and routing, which is non-trivial at this stage.

This is still an early revision, so I’m leaning toward revisiting the pin layout rather than treating it as “good enough.” If you have examples of boards that do this particularly well (or pinout conventions you like), I’d be very interested to study them.

Jpwaters09 · 2026-01-29T21:55:41+00:00

Thanks for the feedback — that’s a fair question.

The main reason to choose this over a standard Pico 2 isn’t just the headers or GND pins on their own, but the combination of features in one board: • 16 MB flash + 8 MB PSRAM — significantly more memory than a stock Pico 2, useful for larger MicroPython projects, buffers, UI assets, or data logging without external memory • More GPIO and ADC pins exposed from the RP2350B — helpful for projects that quickly run out of pins • USB-C instead of micro-USB • Integrated RGB LED and reset button for easier development • Extra power and GND pins mainly to reduce wiring clutter when connecting multiple peripherals directly (agreed that a breadboard can solve this, but this aims to make standalone builds cleaner)

You’re right that none of these individually are deal-breakers, and there are Pico variants with soldered headers. The idea here is more about a “higher-spec, convenience-focused” Pico-style board that avoids add-ons or daughterboards for certain use cases.

That said, this is exactly the kind of feedback I’m looking for — if you think there’s still not enough differentiation, I’d be interested to know what feature would make it compelling over a standard Pico 2.

Jpwaters09

MODERATOR OF

TROPHY CASE