It’s a pity the TM actively fights wifi. If it was documented unsupported and left at EP discretion (with a strong suggestion to wire), that would be one thing, but it seems the RPi version has it hardcoded to only announce over wired networks.
I have got TM pretty much working on Raspberry Pi Zero-W, and that would make for a great skills display, for example, which is nice to have for us (small Vex IQ event), but certainly not mission-critical (if it fails, no big deal, the skills referee could just turn off the screen).
Now, don’t get me wrong. I am certainly grateful for the RPi remote display feature (and TM in general, which is a wonderful piece of SW). But having it wired-or-nothing pretty much means no skills display for our tournament.
I wouldn’t recommend that, for probably the same reason they don’t enable the built in wifi on the Pi 3: it’s all 2.4Ghz wifi. I would stick with an external extender with an ethernet port that is 5ghz like this no brand one or this netgear one. You can go cheaper and get some 2.4 ghz ones, but you can clutter up the spectrum, especially if the pits and tournament are in the same large room.
We don’t “actively fight” it. The user guide says pretty much exactly that - it’s not supported, we don’t recommend it, and if you absolutely have no choice it gives some advice.
Nothing has been actively done in any of the TM code to purposely prevent it from working on wireless networks. The Pi image that we distribute contains everything it needs to make TM function. It does not include the drivers for the wireless chips in the Pi3 because those are 2.4GHz only, and using it would cause interference with the robot controls.
There’s nothing magical about the Pi Zero W. We’ve had TM running on it for a long time. The problem is, we’ve tested it and we do not feel it performs acceptably (it uses the same microprocessor as the original Raspberry Pi). Plus, it does not have a wired network interface, which means most people would try to use it wirelessly. And, as we keep telling everyone, that’s not a great idea.
Everyone, please understand we don’t make these recommendations to annoy you. I’d honestly be thrilled to tell everyone that you could use a Pi Zero W and have a completely wireless field (except power). We’ve evaluated that and we do not feel that solution is robust enough. Maybe someday it will be. For right now, though, it presents too many issues and potentially can affect the integrity of your event, so that’s why we recommend you not do it.
A number of us worked very hard to get the Pi solution done and available for all EPs. One of the major concerns in doing that was introducing a new set of problems into events and the inevitable support burden that represents. When we see EPs trying to manipulate the official software image that we distribute in order to enable wireless USB adapters which we explicitly recommend against frankly can make it more difficult to release similar new features in the future.
I stand corrected. I assumed (more than I should) based on the observation that the display doesn’t show IP address when attached over wifi and neither have I seen the display listed in TM on a PC.
But I have since verified that I can at least add the display IP manually to TM and then it works
Not really magical, just different - ARMv6 vs ARMv7 on newer PIs, and when some SW gets compiled for v7, no dice on Pi Zero. Since the docs explicitly specify “2 or 3B”, I assumed. My bad.
I hear you. We will get those wires there somehow. And I do have Pi 3B to use for that.
Thanks for making TM available for RPi and sorry if I sounded little too offensive.
Sometimes, it’s about managing expectations (and I understand given my track record above I am disqualified from giving suggestions, but consider this):
“Use TM on RPi3B. Yes, it would run on Pi 0, but you won’t like the performance.”
“Yes, it is technically possible to use WiFi, but especially on 2.4GHz, it would interfere badly with your robots”
We drive the students to ask questions. We teach them to not take “It won’t work” for an answer. To seek understanding and test boundaries. Yes, they can be annoying asking their "why"s afterward
If it worked for you, great. Honestly we’ve done a lot of work to try to make things more robust in that area. However, I take issue with the bolded part (and maybe that was intentional - it really reads that way to me but perhaps it wasn’t meant to be).
As I’ve said in other threads before, it’s easy for you to say it worked great and that others should do it against our advice. But that’s because you’re not the one that’s going to get a phone call when the event possibly falls apart because someone listened to you instead of us. Please keep that in mind.
We’re just running pit displays. It’s not exactly show stopping if they bug up.
That said what we did wasn’t complicated and any issues we have are internal Network problems. All we did was set up a WiFi extender and a router, connected the wifi extender to the router and then plugged a network switch to the extender. It saved us from running 100 feet of eithernet and taping it down.
I’m sorry you have issues running remote IT support, but IT support in general is nightmare fuel so despite what I or anyone says that’s going to be obnoxious.
I’m honestly surprised you guys offer support for a free software.