[FRC Blog] Radio Silence

[Hallry]

Posted on the FRC Blog, 6/3/16: http://www.firstinspires.org/robotic.../radio-silence

Radio Silence

Written by Kate Pilotte, Kit Of Parts Manager & Kevin O'Connor, Robotics Engineer.


The Open-Mesh OM5P-AN radios used in the 2016 FIRST STRONGHOLD season were great for our use case in so many ways (smaller form factor, effective random backoff, etc.), but alas, as of June 1, they are not available for purchase! Why? Because they’re not legal for sale per the Federal Communications Commission 14-30, ET Docket No. 13-39 (specifically the modification to 2.1033(b)(13)). Basically, the open nature of the firmware was too permissive, and regulations are now in place to make sure that wireless firmware meets specific requirements.

Open Mesh has a new radio, the OM5P-AC, which we’re currently evaluating for the 2017 season, however we can’t yet definitively say that it’ll take the OM5P-AN’s place. In parallel, we’re working to make sure that the OM5P-AN will still work and be FRC-legal for the 2017 season, but we can’t commit to that yet either. If we can go in this direction, Open Mesh will work with us to get the FRC specific firmware signed off and legal for purchase.

We totally get that this is frustrating to those of you that invested in the –AN and even more so to those counting on getting new ones for off-season events. We’re sorry we don’t have firm answers for you yet.

Meanwhile, if you’re attending an off-season, here are some things for you to know:

• You can still use the OM5P-ANs (just don’t try to sell any).
• You can also use the old DLink DAP-1522 radios, but will need to manually configure them per the instructions posted in the 2014 Control System Screensteps.
• If you’re really stuck and have no radio, please contact frcparts@usfirst.org and we may be able to loan you a used radio from event Spare Parts cases (while supplies last).

As we confirm the unknowns mentioned above, we’ll keep you posted.

Kate & Kevin

[SenorZ]

Good to know, since they're really pricey too.

[Ginger Power]

Please don't pick another radio that has a 90 second reset time... watching robots die on the field this year was especially frustrating (and common) because you knew it would be for a large majority of the match.

[marshall]

Meh, not a huge deal either way. I'd like to see them jump to the next generation and get us more bandwidth though. Always a plus.

[Conor Ryan]

I hope the new radios get a back up power supply.

[tjf]

Originally Posted by Conor Ryan

I hope the new radios get a back up power supply.

Pretty sure that'd conflict with R31, as the only exception I've seen is a device that needs a battery to function and will not without it, eg. a smartphone used for vision (like 254).

Otherwise, I'd have stuck a capacitor on the radio to make sure it stays on in the event of a brown-out.

[AdamHeard]

Originally Posted by tjf

Pretty sure that'd conflict with R31, as the only exception I've seen is a device that needs a battery to function and will not without it, eg. a smartphone used for vision (like 254).

Otherwise, I'd have stuck a capacitor on the radio to make sure it stays on in the event of a brown-out.

If FIRST is working with someone to spec a radio, I'm sure they would allow themselves to write rules that made it legal.

[tjf]

Originally Posted by AdamHeard

If FIRST is working with someone to spec a radio, I'm sure they would allow themselves to write rules that made it legal.

From what I understand, the problem isn't the hardware, but the firmware on the device allowing the user to change the frequency outside of FCC regulation. For FRC to specifically request OpenMesh build an integrated and mandatory power backup would be complicated and costly. (imho)

The main problem, for me at least, is that the radio takes 90 seconds to boot... If they're working together on a custom FRC firmware why not make one that just boots faster and disabled unneeded features?

EDIT: Approximately 90 seconds, numbers were based on a match I watched and wasn't exactly counting with a timer. Take with a grain of salt.

[Alan Anderson]

Originally Posted by tjf

The main problem, for me at least, is that the radio takes 90 seconds to boot... If they're working together on a custom FRC firmware why not make one that just boots faster and disabled unneeded features?

I don't think I ever saw one take more than 60 seconds. 45-50 seconds was more typical. The rest of the delay some people are noticing is from the Driver Station sometimes taking upwards of 20 seconds to establish communication once the network connection is there. That appears to be a Windows networking thing.


It's my understanding that the bulk of the OM5-AP bootup time is in loading and initializing the built-in web server interface to the device settings. If that were removed from the firmware package, it could probably boot in less than 30 seconds. It would also take away a lot of flexibility for teams to tweak their network setup.

Given a couple of years with the same radio, I expect that the bootup time could be drastically slashed while providing teams with the appropriate tools to configure the device. That's probably not going to happen this year, though.

[Thad House]

One thing I wonder is that if when you configure the radio for field use, maybe the web dash could be disabled. There's no way anyway into the radio after it's been programmed without resetting it, so in competition mode that most likely would not be an issue. Especially as the firmware programmer and team flasher would work anyway without the dashboard.

[GeeTwo]

Originally Posted by Conor Ryan

I hope the new radios get a back up power supply.

Originally Posted by tjf

Pretty sure that'd conflict with R31, as the only exception I've seen is a device that needs a battery to function and will not without it, eg. a smartphone used for vision (like 254).

Otherwise, I'd have stuck a capacitor on the radio to make sure it stays on in the event of a brown-out.

Originally Posted by AdamHeard

If FIRST is working with someone to spec a radio, I'm sure they would allow themselves to write rules that made it legal.

Last year's R31 exception to the main battery read:

Additionally, batteries integral to and part of a COTS computing device or self-contained camera are also permitted (e.g. laptop batteries, GoPro style camera, etc.), provided they’re only used to power the COTS computing device and any peripheral COTS USB input devices connected to the COTS computing device and they are securely fastened to the ROBOT.

So, even with the same rule, a battery integral to the radio in its COTS state would have been legal. All they'd have to do is not disqualify it in a blue box or Q&A by deciding that the radio was something other than a computing device.

[notmattlythgoe]

Originally Posted by GeeTwo

Last year's R31 exception to the main battery read:


So, even with the same rule, a battery integral to the radio in its COTS state would have been legal. All they'd have to do is not disqualify it in a blue box or Q&A by deciding that the radio was something other than a computing device.

Or we could just go with the fact that R31 currently does not exist for the 2017 season and does not matter in this discussion...

[marshall]

Originally Posted by notmattlythgoe

Or we could just go with the fact that R31 currently does not exist for the 2017 season and does not matter in this discussion...

Are you saying "change is coming"?

[MrRoboSteve]

No question that boot time is a big downside of the OM5P-AN. It's ~60 seconds, compared to ~25 seconds for the previous d-link radio.

Considering the optimization target "number of seconds of robot-match time when the robot sat there unable to communicate", it is far superior to the d-link.

[tjf]

Originally Posted by Alan Anderson

I don't think I ever saw one take more than 60 seconds. 45-50 seconds was more typical. The rest of the delay some people are noticing is from the Driver Station sometimes taking upwards of 20 seconds to establish communication once the network connection is there. That appears to be a Windows networking thing.


It's my understanding that the bulk of the OM5-AP bootup time is in loading and initializing the built-in web server interface to the device settings. If that were removed from the firmware package, it could probably boot in less than 30 seconds. It would also take away a lot of flexibility for teams to tweak their network setup.

Given a couple of years with the same radio, I expect that the bootup time could be drastically slashed while providing teams with the appropriate tools to configure the device. That's probably not going to happen this year, though.

I hadn't taken that into account, mine was from when the robot stops moving to when the DS can move it successfully. Just for the sake of clarity, my total seems a bit larger, though roughly similar to the numbers you've seen. I wasn't exactly counting, it was during me watching a match I saw it happen and got my numbers, so take it with a grain of salt.

Though this is just my two cents, but if the device prioritized services (DHCP & Routing) above the webGUI, it'd help boot times, though this might be totally contrary to the way OpenMesh has the device configured.