TeensyMaestro

Oleg -

Just curious, why aren’t you using the ribbon cable that comes supplied with the Ethernet kit? That could eliminate a possible variable in your situation.

Hi Len,

First of all, thank you for making TeensyMaestro available to the community. I am building a V2.001 project on HW V2 and I am very pleased with both the hardware and software, and the functionality it provides.

My FlexRadio is located at a remote QTH in the forest, with no PC or server present, just the FlexRadio and a router. I access the radio via VPN (TAP mode), where the router acts as the server. This setup works fine, my PC connects and I can run SmartSDR locally.

Initially, I tried to bridge my PC’s OpenVPN connection to the TeensyMaestro using an external USB Ethernet dongle. While it kind of worked, Windows had difficulty passing DHCP across the bridge, and I had to resort to using a static IP for the TeensyMaestro. Unfortunately, the bridge introduced networking quirks on the Windows side, so I started searching for a cleaner solution.

Connection Modes

I modified the code to support three different connection modes specified in the MMConfig.ini:

Auto Discovery: Behaves like the original TeensyMaestro, using Flex UDP discovery on the local LAN.
Fixed: Connects directly to a specified hostname or IPv4 address (with port).
Fixed + Failover: Tries the fixed hostname/IP first, and if that fails, falls back to Auto Discovery.

This means that my TeensyMaestro can now connect to any FlexRadio across the Internet, independent of the PC. I just plug it into any network outlet with Internet access,and it connects directly to my radio. For many Flex owners with remote stations, this is a common use case.

MTP / SD Card Access

The only part I have not been able to get working reliably is MTP (to expose the SD card to Windows as a portable device). With the original precompiled HEX file, I sometimes saw the Teensy SD card appear as a drive in Windows, but after building my own firmware it never shows up. I would very much like to know exactly which MTP and SD libraries you used, which versions, and whether you had to apply any patches or shims to make it work reliably.

Main Question

Do you think it is acceptable that I use and extend your source code in this way for private use? If so, would you also be interested in a pull request or patch set with my changes, so this capability could be included in the official firmware? I currently keep my changes in a private GitHub repo, but I believe many users would benefit from being able to connect their TM directly to their FlexRadio without setting up double SoftEther servers or complex bridging workarounds.

Thank you again for all the work you have put into TeensyMaestro. I am very impressed with what it can do,and I would be happy to contribute back if you think this direction makes sense.

Hello Oleg

I would very strongly recommend you purchase an official ethernet kit for the Teensy. It will be a much more robust and reliable set up with a proven design. I think you are opening yourself up to problems with your setup.

They are fairly inexpensive and available on Amazon. https://a.co/d/7Y12P3K

Hi Oleg,

Oh, I just realized you may have been considering connecting that device to the SPI bus. The current Teensy Maestro firmware would not support that.

I'm uncertain if the Teensy 4.1 would have the correct Arduino libraries to support a W5500 Ethernet PHY chip connected via SPI. Because the Teensy 4.1 already has an onboard PHY chip, I would think it's unlikely.

Oleg,

not sure what pins you are refering to, look at the schematics https://www.pjrc.com/store/ethernet_kit.html

And make sure the magjack you are using is internally identical to whan used. Having signals on RX+ but not - makes me suspect the magjack, or mixed up pins :)

/Lasse

@K3CDY Did you have to do anything special to get OpenMTP (on MacOS) to detect your Teensy? Mine refuses to show up.

Hi Bill,

Thanks very much. It looks like the usb mini to usb c adapter I was using was causing me issues. Jonathan who bought one of my kits reached out and suggested a fix* which has it working exactly as you suggested.

*The solution was to use a usb c to usb a cable.

73, Neil.

I want to take a moment to express my gratitude once again to everyone involved in this project. It has given me so much, not only the joy of building the hardware itself, but also the opportunity to expand and customize the software with features of my own. That ability to add functionality is truly inspiring and opens up endless possibilities. For me, it has become a really enjoyable side project and hobby alongside amateur radio.

I would also like to share a picture of my setup. In my case, I’ve made use of the often unused area for slice B to display a small clock widget. It shows the time in any time zone, synchronizes with an NTP server, and provides some additional useful information.

Many thanks again to Len, KD0RC, Simon, NV0E, and everyone else who has contributed their time and effort. Your hard work and dedication are very much appreciated.

Hi Len,

I’ve now built a fresh WinKeyer v2–compatible interface for TeensyMaestro (Teensy 4.1) and have been testing it with DXLog.net. Because it follows the WK2 protocol closely, it should also work with other loggers that speak WinKeyer 2.0+. (untested though…)

Highlights

• TCP/IP transport for WinKeyer (tested with DXLog).
  Serial transport is planned and already scaffolded in the config (COM name, baud, 8N2, etc.).
• Tight integration with the built-in keyer (no external timing engine). WPM changes apply deterministically at character boundaries, and the keyer does the actual timing.
• Unified RX FIFO (ASCII + buffered commands in the same queue, interpreted at dequeue): deterministic ordering, fewer race conditions, simpler mental model.
• Buffered speed (<1C>) behaves like K1EL/K3NG: armed, then applied at the next character boundary.
  We also restore the baseline WPM on disconnect (whatever WPM was present when the host opened the session).
• Local dial → host sync via WK “speed ****” status bytes, with idle-only notifications to avoid ping-pong with the host.
• Implemented commands (short list):
  Admin Open/Close, Set Speed <02>, Speed **** Limits <05>, Clear Buffer <0A>, Request Status <15>, buffered PTT/WAIT/Speed (<18>/<1A>/<1C>).
  Set Weighting <03> is accepted and stored (25–75) for compatibility; timing adjustment is not enabled yet.

Practical notes

• RAM1 is kept tight; no parallel queues or special out-of-band flags.
• Config is INI-driven (TCP port, enable/disable, placeholders for COM).
• The current implementation lives in my dev branch (quite a lot has changed there… ). If there’s interest, I can post a ready-to-try HEX in my repo so you can test without merging code.

Totally understand if this isn’t something you want to pull into TeensyMaestro proper. If you’re curious, feel free to cherry-pick anything useful from my dev branch. And if you have any questions or would like me to prep a test build, just drop me an email.