Received our first UPA a couple days ago. It took a while to get started, and we found some issues that really ought to be resolved (hopefully in software!); here are our observations:
Netinstall
Unlike the RB750UP, holding down the OmniTik UPA’s reset button does not cause any of the LEDs to light up or go out, so I had to guess how long to hold it down before releasing it. On the 750UP, you hold it down ~10 seconds until the “ACT” LED starts blinking, continue holding it down another ~15 seconds until it stops blinking, then release it. So I held down the button on the UPA for ~30 seconds before it would go to netinstall. Once there, it behaved as expected.
The remainder of the observations apply to ROS 5.14.
LEDs
The correct LED blinks to show activity when a device is plugged in, but a different LED lights up red when PoE is in use. (PoE on Ether2 blinks LED#2, but turns LED#5 red; PoE on Ether3 blinks LED#3, but turns LED#4 red; etc.)
LEDs often remain red even when the corresponding device is disconnected from the UPA–even after rebooting the UPA!
PoE
Upon first boot, all the Ethernet ports had PoE-out disabled. But whether I set them to auto-on or forced-on, I couldn’t get them to power any of the RBs in my lab. Only after I rebooted the UPA (after upgrading the boot firmware from 2.37 to 2.38, if that makes a difference), did the ports start supplying PoE.
Hot-plugging a device into Ether2 or Ether3 will cycle power to the devices in Ether4 and Ether5, regardless of their types.
SXT
Our newly-delivered SXTs experience multiple “false starts” powering up when connected via Ether4 or Ether5, regardless of what (if anything) is powered via Ether2 and Ether3.
Our RB711-2HnDs do not have this problem when plugged into any port. And it isn’t a matter of load: With the same four devices (two SXTs & two 711-2HnDs) plugged into different ports, the SXTs in Ether2 and Ether3 start up fine, as do the 711-2HnDs in Ether4 and Ether5.
Could be related to the power-cycling behavior of Ether4 and Ether5 noted above.
Winbox & Command
/interface ethernet export does not include poe-out states.
Upon reboot, Winbox indicates that all five Ether ports have PoE disabled, regardless of their actual states.
PoE cannot be turned off–neither via winbox nor the command interface.
As a suggestion, when PoE is set to auto, it would be helpful to have an indication as to whether PoE is actually being used on that port.
Please contact support with the supout.rif file from this device, we will check if this is software or hardware related. I am sorry you had such experience with your first device.
a sextant plugged in port 2 is not getting power anymore, even rebooting omnitik
!!! omnitik ethernet negotiates only 10mbit !!!
setup:
sextant — omnitik — rb751 — omnitik — sextant
of course omnitik models are with poe out and 751 is not, so we are using 3 power supplies here. 10mbit makes all this 802.11n useless, please fix this!!
Anybody already know what this red led is all about?
Indeed very frustrating when you buy something and it start behaving weird and there is no proper manual!
A red LED signifies that a port is being used to supply PoE. The only problem is, the wrong LED lights up red! #2 and #5 are interchanged, and #3 and #4 are interchanged.
Suppose you plug only one device into the RB750UP; for example, an RB411 into ether2. LED #2 will light up green to indicate port activity, and LED #5 will light up red to indicate that PoE is being provided (via ether2). After you experiment with it a bit, it will make sense. But I do hope they come up with a fix for it–preferably at the firmware/driver level rather than in hardware.
Is this going to fixed or do we just have to live with it? Is it going to be mentioned in the manual?
The manual doesn’t even speak about a red light! So, like me, most users seeing this for the fist time are worried about it. If you don’t know you might think the unit malfunctions!
But… is the fact that the power-indication lights are reversed on the OmniTik UPA going to be fixed? If so, will the fix apply to existing units (e.g., via firmware), or will only newly-manufactured units be corrected?
LED order on Omnitik UPA-5HnD cannot be fixed. That is a hardware problem and LEDs are actually wired through PCB in wrong order. Only “workaround” for this is when PoE controller firmware will be capable of showing port PoE out actual state in /interface ethernet print, so that LEDs can be ignored completely. However that feature is not ready yet.
It could be fixed in firmware if each red LED could be configured in ROS to indicate PoE for any given port; then the owners of reverse-LED OmniTiks could just (re)configure them accordingly.
A visual indication of status that does not require additional equipment is useful. Just because Winbox is able to show the status, does not make the LED output worthless; otherwise there would be no reason to have the green LEDs either.
This also begs the question: will there be a hardware revision in which the LEDs are wired correctly?
if it could be fixed it would have been fixed already. Me saying it cannot mean just that.
A visual indication of status that does not require additional equipment is useful. Just because Winbox is able to show the status, does not make the LED output worthless; otherwise there would be no reason to have the green LEDs either.
it is very useful if device is on the table, later on when it is installed outdoors - it is not that handy any more, is it?
This also begs the question: will there be a hardware revision in which the LEDs are wired correctly?
