[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.

[JohnFogarty]

Originally Posted by 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.

+1

[synth3tk]

Originally Posted by 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.

As a volunteer who is unfamiliar with the tech used in the bots now, this explains a lot. I couldn't understand why a bot would go dead, then start moving again near the end of a match. That sounds like a horrible amount of time to be out-of-commission.

[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.

[maxnz]

Originally Posted by synth3tk

As a volunteer who is unfamiliar with the tech used in the bots now, this explains a lot. I couldn't understand why a bot would go dead, then start moving again near the end of a match. That sounds like a horrible amount of time to be out-of-commission.

During our very last match of the season, we lost connection and regained it near the end. Our driver was amazing, though, because he was able to swing the match from a 0RP to 4RP match with only 30 seconds before the match ended. More details here (post #9): http://www.chiefdelphi.com/forums/sh...d.php?t=148565
That was the first and only time we ever had a problem.

[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.

[Rangel(kf7fdb)]

Personally I favored the old radios that had 4 ports. This year we had a radio go bad and constantly had problems connecting in our build room. Could be user error or radio problem. All I know is it worked one moment and didn't work another moment with no configuration or connection changes. I also prefer having more ports so that we could connect to the radio via Ethernet without having to use a splitter when the ports were already maxed due to an on-board computer. Also if one port went bad on the old radio, it wasn't totally gone since you could just use a different port.

[Chris is me]

Can we please pick a radio with a physical Reset button... if you can't connect to the router because the firmware is messed up, you can't reset it to factory settings either, and that's kind of a terrible catch-22 to be stuck in!

Also I'll add to the growing requests for a radio that boots in less than 90 seconds... This is the single biggest thing, really. I don't understand why minimizing this aspect of a radio isn't a top engineering priority.

[notmattlythgoe]

Originally Posted by Chris is me

Can we please pick a radio with a physical Reset button... if you can't connect to the router because the firmware is messed up, you can't reset it to factory settings either, and that's kind of a terrible catch-22 to be stuck in!

Also I'll add to the growing requests for a radio that boots in less than 90 seconds... This is the single biggest thing, really. I don't understand why minimizing this aspect of a radio isn't a top engineering priority.

More than 2 ports would be wonderful also.

[Jon Stratis]

Originally Posted by Chris is me

Also I'll add to the growing requests for a radio that boots in less than 90 seconds... This is the single biggest thing, really. I don't understand why minimizing this aspect of a radio isn't a top engineering priority.

I would say it's a top priority for our use... but for a vast majority of use cases, a boot time of 30 seconds versus one of 90 really doesn't make that much of a difference. When you're sitting at home and the power goes out and comes back, do you sit on your couch complaining that your home wifi router takes too long to reboot? And even if you do, does it happen often enough for boot time to be something you actively look for when picking your next router? Companies making routers know that most of the consumer base they're trying to attract won't really be impacted much by the boot time, and instead are looking for things those users do want - small size, strong signal, easy to set up, a nice UI, good security, customizability, etc. So all of that gets prioritized over boot time.

Besides, if it had amazing fast boot time, the engineers working on it wouldn't have any more excuses.