Is there any reason to not allow anything above 4 mbps?


#21

That’s good for the field but why haven’t the robot’s coms also been changed to 5ghz


#22

It’S pArT oF tHe ChAlLeNgE!

(Seriously though, they are doing you a favor - no way did we actually get the promised 7mbps at Houston Champs last year)


#23

The robots connect to the field radio via 5ghz. Read the FMS Whitepaper for more info.


#24

I’m not sure about Java 11, but at least in Java 8 the Nashorn Javascript engine could connect to the same exact cameras that Google Chrome could. So if the camera could compress to h.264, then there would be a way to bring it up in Shuffleboard. We plan to experiment with the same thing in our own UI this year.


#25

Who do you imagine the field is talking to?
It doesn’t communicate with anything but robots using 5GHz.


#26

(Un)fortunately Nashorn was heavily deprecated / removed in Java 11 as part of JEP 335.

https://openjdk.java.net/jeps/335


#27

Yeah two years ago the latency grew exponentially past 5 mbps. I’d rather have a lower bandwidth reliable connection than a higher bandwidth fickle connection.


#28

Pics or it didnt happen on that 1050Ti


#29

@solomondg can probably elaborate, but its on the left side of the bot.


#30

You could also argue that they’re simulating a limited bandwidth to another planet, or that requiring this limitation makes autos more important.


#31

Last year I worked with several teams that were ‘maximizing the bandwidth’ at 7mb. The FTA would show me the team b/w while on the field. I think things ran ok with one team did this, but if two or more teams with the same usage were on at once, network traffic started to lag.