View Single Post
  #52   Spotlight this post!  
Unread 29-01-2008, 09:16
Jon Stratis's Avatar
Jon Stratis Jon Stratis is offline
Mentor, LRI, MN RPC
FRC #2177 (The Robettes)
Team Role: Mentor
 
Join Date: Feb 2007
Rookie Year: 2006
Location: Minnesota
Posts: 3,839
Jon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond repute
Re: Robocoach signals loophole?

Quote:
Originally Posted by dlavery View Post
If you are using a standard commercial IR remote control, you are already doing this.

When you mash the "3" button on an IR remote, the device does not just send "3" out over the IR LED. That information is actually buried inside a larger packet of information that is sent each time a button is pushed. The packet will typically contain (as a minimum) synch pulses, the target device address, an encoded version of the data, and termination pulses.

Depending on the device being used, the actual "data" content can be a small fraction of the total transmitted packet. For example, if the remote uses the Control-S protocol (used by Sony - the two most common protocols are from Sony and NEC), you get a header pulse, a seven-bit data block, a five- eight- or thirteen-bit target block, and a trailing pulse. Of the data block, only 10 of the 256 seven-bit permutations correspond to the numbers on the remote. All the rest of the packet space is used by the remote to encode other information that is used by the receiver to decode and direct the data.

So what is being proposed as an advantageous "loophole" is, in fact, already in place and the rules support and accommodate it.

-dave



.
Yeah, i understand how a remote typically works - the only real difference between programming a remote to send multiple signals every button press and that is the possibility for interference. There are only so many manufacturers, and each of them only has a few different types of signals they use (if you look at the instructions for a programmable remote, they usually have a lookup table by brand with at most 50 or so values). By using a standard remote with a standard (single) signal for each button, you risk that someone else is using the same type of remote, or is programmed for the same brand and you risk their commands telling your robot what to do. With the sizes of the regionals, odds are this'll happen to someone at each regional... by encoding longer messages, you significantly reduce or even eliminate this risk, and that is really the part that isn't already contained within the general understanding of the rule.