shawn

Try calling flush() on the client after writing data if you’d like it to get sent immediately. There’s no need to delay() or yield(). TCP buffers will get sent either after a timeout, about 250ms, or after a flush. See also...

What about adding an implementation of __gnu_cxx::__verbose_terminate_handler() somewhere for reduced code size when using non-smallest build options? Then again, it's not really a "serious bug". Here's what I do in the QNEthernet library: #if...

[...two days later...] [again, in a French accent] I believe I've solved it this time. I'm now seeing speeds greater than 19Mbps over the "direct" link (Belkin Ethernet USB-C adapter). I'm using much more aggressive buffering. Also, I'm leaving...

I would suggest that you create a new topic on this. It might help if you also give a link to the device that you are trying to plug in. You might also try the HIDDeviceInfo sketch and include any information from it, like the Descriptor...

I confirm these outputs also :) I used a SFP based ethernet media converter (this is my "direct ethernet access" to the PC) and Wiznet still struggles as far as this scenario is concerned.

Could you try setting your Ethernet port’s MTU to 1400 and see what happens? And then 1280.

@PaulStoffregen I changed the MTU for the network the Teensy is attached to (Belkin adapter) to 1280 and then to 1400, down from 1500. The speeds are dramatically improved, like by a factor of 10. Would you be willing to try that? I also tried...

If I run "git log", the latest commit it prints is: commit c11e8bb2c6819f40d9739c833baf24f3bf646387 (HEAD -> master, origin/master, origin/HEAD) Author: Shawn Silverman <email redacted> Date: Thu Feb 12 20:56:14 2026 -0800 w5500: Remove...

Another issue I'm experiencing is that ping doesn't work. I haven't dived too deeply using Wireshark or anything, but I'm just not seeing ICMP Echo Reply packets after sending multiple pings out the Teensy/W5500.

I wonder if restarting the PHY is the solution, rather than just restarting auto-negotiation. Once I can duplicate the problem, I'll experiment with that too.

A Friday update: I'm still in the process of acquiring parts to duplicate the setup. (The setup that was experiencing problems was already shipped to the show.) I have the same 24V power supply, same WS2814 24V LEDs, and same 12/24V-to-5V voltage...

For posterity, here were my results from yesterday with the Teensy->W5500 (WIZ850io)->eero node->wireless->Mac laptop: ------------------------------------------------------------ Client connecting to 10.0.0.21, TCP port 5001 TCP window size...

Was this W5500 measurement with the latest on github?

Interesting. Thanks for having a go at that. I think I was seeing upwards of ~11-14.7Mbps with the Teensy->Wiznet->eero->wifi setup, and about the same speeds as you’re seeing when using the wired adapter. Both tests with 30MHz SPI. Something’s...

I finally found the issue!! :) Well, issues. ...five days later... [In French accent] I tried everything I could think of, from different Ethernet-USB-C adapters to a multitude of adjustments to the code, to different packet sizes, to examining...

I use it very frequently (for both commercial and non-commercial projects) and it’s very stable. There are lots of additional features in the QNEthernet library that other Arduino-style libraries don’t have. It can be installed via the Arduino...

…but they both require at least one or two register reads (without an actual interrupt line): either just the size available or, with interrupts, the interrupt register and then the size register. We probably have the same W5500 module; I’ll see...

Polling. I should try out the interrupt approach…

Here's an update with the QNEthernet W5500 driver: I've been trying to improve it by focusing on receive buffering. Instead of reading one frame at a time from the chip, I'm now reading and buffering the chip's whole RX buffer, which may contain...

Definitely update to Teensyduino 1.60-beta6. There were lots of fixes. I’m not actually sure if it will impact your project, offhand, but try it.

Yep. Paul’s Ethernet library is the way to go for speed, with a W5500. I think the reason the QNEthernet library’s W5500 driver is so slow is because it uses that MACRAW mode. I use it for raw frames only and provide the TCP/IP stack on the CPU...

Agreed. Probably due to the raw frame processing, would be my best guess.

Some additional guidance: If you happen to look at driver_w5500.c: 1. PHY initialization in driver_init() (and then low_level_init()) 2. driver_proc_input() polls for input frames 3. driver_poll() is called regularly to check link status 4...

Steps: 1. Uncomment QNETHERNET_DRIVER_W5500 in qnethernet_opts.h 2. Change any parameters you need in qnethernet/drivers/driver_w5500_config.h 3. Build and run the IPerfServer example as normal Depending on your setup (for example, my tests were...

I'd like to report absolutely dismal performance with QNEthernet/W5500/IPerfServer example (note: the driver uses MACRAW mode): I'm seeing about 350 Kibps. That's at 30MHz SPI. At 14MHz, < 200 Kibps. I tried with both interrupts enabled (not the...

I looked briefly at the Nucleo-F412 benchmark code. Looks like they're just receiving all incoming data without any parsing of iperf's info. So I tried to create a similar very simple benchmark. I also added a Mbit/sec bandwidth print every...

I can have a look more tomorrow. Do you feel like trying out the original version with QNEthernet plus its W5500 driver? You should only need to uncomment “QNETHERNET_DRIVER_W5500” in the qnethernet_opts.h file.

Just another reminder that something changed with the iperf 2 protocol so, for example, the “-r” feature doesn’t work anymore. It’s on my to-do list to figure out.

I got it compiling. There were two issues: 1. ntohl(), et al, may already be defined somewhere, so I wrapped those in #ifndef/#endif pairs. 2. I don't quite understand why yet, probably something to do with sometimes-weirdness of Arduino.h...

@PaulStoffregen, working on it now...

Sorry, what I meant was what protocol did you use? Iperf has its own protocol that needs to be parsed. I was wondering where you got details on parsing the iperf stuff.

@istrateandrei26 I'm curious which code you used to handle the iperf protocol when you were testing?

Thanks! Yes, it works quite well, but over the last year or two, something changed in the iperf (v2) protocol, so a few features that used to work when I wrote it have changed somehow. Also, the documentation I had to work with was the source...

May I suggest trying to duplicate their results? That may provide insights on what they’re doing.

Hi everyone, Thanks for adding me to the FORM I’m looking for some guidance on designing or sourcing a enclosure for a Teensy 4.0 lockable My initial thought was to go 3D-printed, but a lot of the examples I’ve seen don’t look very polished...

I've also got this problem now, and the solution mentioned above does not work for me. I can't get the link back up without reseating the ribbon cable to the network jack, or power cycling the Teensy. I can never remember having this problem...

Apparently, I posted about this before: https://forum.pjrc.com/index.php?threads/add-option-to-teensy-loader-to-set-utc-time-and-not-local-time.77042/ The salient link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html...

When Teensy Loader uploads some firmware, it also sets the Teensy's clock. The value it's sending is incorrect. It looks like it gets the current system time from the computer and then adds the time zone offset. For example, it's about Wed Feb 4...

Which Ethernet library are you using? Because you’ve done some iperf measurements, I’m guessing QNEthernet? (IPerfServer example.) Assuming that’s true, the reason may be due to how the W5500 driver is written. It uses raw frames and the lwIP...

It takes using the new JSON :: https://www.pjrc.com/teensy/td_160-beta6/package_teensy_0.60.6_index.json To know about the new beta. And the Beta numbering for 1.60 is 0.60 so it won't suggest forcing a new beta over a release build - that's...

The updates through the Arduino IDE don’t usually propagate for a day or so.

I just released v0.34.0. Here's the Changelog: ## [0.34.0] ### Added * Added tests for some of the print utility functions and classes. * Added the `QNETHERNET_ENABLE_PING_REPLY` macro to disable ICMP echo replies. * Added a "Requirements"...

I just realized that all the driver functions are included in <QNEthernet.h>. There’s no need to do that forward declaration.

Update: It's been a few days, and I haven't seen the Ethernet freeze since implementing the renegotiate-on-link-down fix. It seems to be working. Here's some sample code (with a bonus abortAll() call): #include <QNEthernet.h> using namespace...

Update: after implementing a call to driver_restart_auto_negotiation() when link-down is detected, the Teensy managed to stay on the network. So far. It’s a positive sign, but a few more days will tell us more.

Note: Ping support was added in v0.33.1 and some slight changes will be in v0.34.0.

I will also throw in my vote for using a USB-C connector. Virtually everyone is doing it these days and who doesn't want to be like the cool kids. USB-C has the advantage of being a lot easier to socket. I think everyone needs three tries to...

I just ordered fresh PCBs from OSH Park, both the PJRC version and something very similar to SparkFun's version. I got only 3 pieces of each.

Works for me, even if you only send one to try out. I can make that work.

If I were to build up a couple alternate adapters with different capacitors, would you be able to give them a try in these problematic applications?