Om5p-an, om5p-ac

I recently enjoyed reading Team 900’s paper about using a switch behind their radio. Our team captain wanted to try this on our robots.
I configured a switch (dl-604), and found that the driver’s station could no longer connect with the robot.
I immediately connected the switch to Ethernet on the driver’s laptop, bypassing the OM5P-AN, and connected with the roborio, and the limelight.
I assume I have to reconfigure something on the OM5P-AN, to allow for the operation of the switch. Here is the problem…I cannot get into the programming screen of ANY of the team’s bridges. I am missing a really basic step here.
I followed the FRC instructions for programming the bridge. The instructions say that a wired connection to the bridge has an address of I get connection refused. I try all the default gateways the bridge gives to no avail.
I have not seen any reason to do a factory reset, because the radios work fine with their prior configuration. (I say ‘radios’ because I have two extras from 2019, an om5p-an, and an om5p-ac.)
I am just not sure if there is some simple thing I am not doing that is specific to FRC bridge software or they just don’t respond like regular routers do.
How to set up an om5p-an for use with a switch?
Thanks DF

You need to disable all router on the functions on the dl-604, so that it only acts like a switch. That may or may not be possible with that particular router.


This is your problem. It appears to be more than just a switch. It appears to be a router and switch.

I would suggest finding a reasonably priced unmanaged switch and use that.

1 Like

See this thread for suggestions on switches. Small networking switch needed for eboard?

1 Like

As much as I appreciate your help with the switch…at this point I am much more interested in the bridges.
I think my next move will be to reflash a bridge with openWRT and see if I can get into the bridge that way. This should prove its FRC software, locking me out.
I suspect if I don’t use the switch that team 900 has I won’t get the results they did. The assumption is that tm900 is using the standard FRC software with their bridge.
I will report back after the openWRT reflash.
Thks DF

900 is using the standard FRC software with their radio, and the switch is just a standard unmanaged switch. You don’t want to be using a router as a switch, that will definitely not work. All you want is a simple switch, otherwise you’re basically creating 2 networks which you don’t want.


We liked this switch, because it gets USB power from the Rio.

For the OM5P’s on the robot, the FRC firmware is stripped down and doesn’t include a webserver to browse to. So we can’t use a web browser as a method of access when they’re setup for FRC use. Settings have to be changed using the same methods used by the Home Radio Kiosk or Event Kiosk.

1 Like

Hahaha!!! I am not crazy!!! But here is a weird artifact…once in a while, when I find a new gateway address, I type it in and I get a login screen for the bridge, but no username or password ever works. Now it makes sense.
Right now I am flashing a bridge to see if what you say is true. I am using the andymark.pdf from 2015. brb

I discovered there is no reset button inside the om5p-an, but I did find a four pin connector on the 2.4ghz radio. I2C, perhaps? I will investigate that further.
After reflashing with openWRT, I got in immediately via the default gateway. Hats off to Mr McLeod! I had suspected something of this nature, but I had a nagging secret too.
I have never tried any networking with a Windows machine. I only know Debian/Ubuntu, and thought perhaps I was being hamstrung by my ignorance of Mr. Gates products.
Thanks for your patience, and wonderful advice!
Have a Merry Christmas!

1 Like

It’s a 3.3v serial port that gets disabled in the FRC firmware.

I’m all for exploration and learning so when you figure out routing, double NAT, RFC1918, and how to use a second router on a robot and what kind of benefit you can derive from it, post a white paper. In my experience, some FTAs and CSAs could stand to learn about it too.

Marshall, thanks for the tip. I am not surprised the serial port is disabled in FRC. LOL! I am sensing a theme with FRC involving a great deal of constraints. I will get there.
As far as white papers, I don’t think I have much to contribute yet.
I do enjoy digging into the various components. Yes it is curiosity, but also a chance to learn diagnostics now, before the stress of build season, or during the game.

1 Like

I am curious why you are exploring adding a router to the robot. Is it just for fun to see what you can do or do you have an end goal in mind?

Austin, I don’t know what the team captain wants to do yet. He just mentioned he liked what tm900 had built. He asked me to read the white paper, and see if I can help him with it.
I haven’t been to any matches so I don’t know what the problems are for certain, but he did mention that the frame rate for the robot’s camera slowed down so much as to be unusable. I don’t know what these conditions were. This did cause them to buy a limelight. As you know the roborio and limelight will both take up Ethernet ports on the bridge. I suppose he wants the option of having a third device operating on the robot, communicating over Ethernet.
I just build what they say, I don’t know what about the strategy.

An unmanaged switch with a reliable power source is the best way to do this.


Last year, teams were limited to 4 MB of bandwidth max during a match. Many teams did not adjust frame rates in their hardware or code settings, and thus had cameras that tried to be pushing too much data, and the field server automatically reduced video transmissions when a team maxed out their bandwidth.

The field does not do this.


100% correct!
BW limiting is performed by the OM5-ac/an.
Now as we all know, the firmware on these radios is not perfected. Therefor, you can easily see how bandwidth throttling may not always work properly and situations like Newton 2019 might occur.

I can’t speak for Austin but there are a limited set of individuals that would know what the precise configurations on the field equipment are. There could be additional limiting configurations, throttling, Quality of Service (QoS), traffic shaping, bandwidth management, etc… that are in play across the field network* but no one knows outside of those with NDAs or access to the field equipment.

I will also add that the field AP is a consumer grade Linksys WRT1900ACS and if you scour the internet, you’ll find lots of reports of it being susceptible to interference (everything from microwaves to neighbor’s wifi) and discussions about how to best tweak the signal settings to improve it with no clear answers, which is fairly normal, particularly for consumer grade equipment. I am by no means a wireless signals engineer (cell phones might as well be black magic to me as they can operate below the noise level in urban areas and that is witchcraft) but I feel like I know enough to make an educated guess that there is/has been interference with the signals coming into the field APs and that is why we have the latency spikes, dropped frames, retransmits, and more and it has little to do with the bandwidth that teams are trying to suck up.

*I am intentionally using the words “field network” and not FMS. We all blame FMS for issues but all that does is make the FTA/FTAA/CSAs say “it isn’t FMS” (and then go about ignoring us) when in reality, most people are conflating the field network with FMS and just refer to the totality as “the FMS”. We should start asking about the field network instead and not conflating the two systems.

If you’ve read this far, the best thing you can do is read the updated FMS white paper, which (at least for me) helped to shed a lot of light on how the field network is configured and made it so I blame “the FMS” for a lot less issues - though I’m still a big advocate of making the configurations of all of the field networking equipment public knowledge (shocker there, I’m sure someone has his club ready for me):


What exactly was the issue with Newton 2019? I don’t recall.