Raspberry Pi Pico W as USB Wi-Fi Adapter
91–100 of 138 posts
Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#92Earlier quoted context omitted.
You seem to be all over the place, most of it by not reading the parent's comment. So let's break it all down. > Bad take. Some things are feasible and some things are not, "anything is possible" is a useless framework. It would help if you quoted the entire comment rather than removing the context and further giving a very bad example afterwards: > Example: go convert two smartphones to communicate p2p over their 4g…
> That is a hardware limitation Sounds like a intentional firmware (aka: software) limitation to me?
Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#93Earlier quoted context omitted.
Yes, but. I asked Perplexity Pro the same fact question (sports) three days in a row after correcting its error the first day and having the correction acknowledged with a promise to get it right in the future. Same error on second day, same promise. Third day: correct. Perhaps it needs to be in the "Slow" classroom....
I've never used Perplexity Pro, but I would expect the exact same outcome from Claude, as I don't have cross-session memory enabled. If you do have cross-session memory enabled, I agree this is not glowing performance. If you don't, then I think it's working exactly as intended.
Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#94one million Claude Tokens (assuming you are on opus) = 5 USD = the very dongle you tried to replace. Add the cost of the rasberry pico, you'll have an easier time buying the wifi dongle. The project is cool thought to learn about networks, NAT, Proxys, ect...
Finally hacker news on .. Hacker News. No need for it to be economical cheap.
Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#95Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#96The closest I’ve gotten is using a raspberry pi in the workbench, but for some weird devices that’s sometimes not good enough.
Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#97I’ve been looking for a good solution for doing the exact opposite, being able to connect stuff through USB in my bench, and see them pop up in my office desktop as if they were usb devices. The closest I’ve gotten is using a raspberry pi in the workbench, but for some weird devices that’s sometimes not good enough.
https://www.orei.com/products/usb-over-ethernet-extender-upt...
Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#98Interesting that Gemini said it was infeasible. It should be aware that using a Pico W as a transparent ethernet bridge has been done several times over in open source projects, for example on BlueSCSI (emulating a Daynaport SCSI-Ethernet adapter) and PicoMEM and my own PicoGUS project (emulating an NE2000 Ethernet adapter).
It's often good to approach what llm said as a guidance, and not as ground truth. You can ask follow up questions or point to potential feasibility and it will change its answer.
Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#99Google Gemini is that naysayer senior developer who confidently tells you it can’t be done. Claude is that easy to get along with smart hard working guy who just gets on with it and builds it double quick. ChatGPT is the eager senior developer who says it can be done but can’t actually work it out and fluffs it.
Re: Raspberry Pi Pico W as USB Wi-Fi Adapter
#100> Average 4.75 Mbits/sec throughput Isn't that slow for WiFi? I mean it's an interesting learning experience, but isn't that strictly worse than pretty much any WiFi dongle?
The Pico is USB 1.1, so the upper bound is 12 Mb/s.
- USB FS has a 1ms frame limit (HS is 125µs)
- UBS FS Bulk is thusly limited to ~19 transactions x 64 bytes maximum (HS is 512)
- USB FS Isochronous can do 1023 byte transfers, but you can only fit one of those in a 1ms frame (resulting in a giant quantization hole in the packet)
- Focusing on bulk only: the token packet, ACK handshake, inter-packet bus turnaround time minimums, framing bits, CRC bits, and periodic FS SOF packets mean that the actual theoretical maximum data rate is ~81% of the signaling rate
- Bit stuffing optimality issues (required for clock recovery) eat an additional several percent on most data, up to ~17% on pathological data
Therefore: ~9.5Mb/s is the best theoretical data rate that can be obtained with optimal host and device IP and an ideal application layer.
Realistically, ~8Mb/s is the most one can expect on real hardware with an ideal application (and this is optimistically high in my experience.)