1. Home
  2. Projects
  3. Omega PoE Dock

Omega PoE Dock

  • B

    Hi Scott,

    That is an awesome project. I use a lot of Ubiquity gear, and they have a non standard 24V PoE. Would the circuitry still work with 24V instead of 48V?

    Bas

    0 S 1 Reply
  • F

    I would be interested in this if it supported 24V PoE. Really interesting!
    Are the schematics available? I’ll take a further look at what you’ve provided when I get a chance.

    0 S 1 Reply
  • M

    Are you passing through the Ethernet PHY from the Onion itself, or is this actually a second Ethernet interface itself as well?

    0 S 1 Reply
  • S

    @Earl-Baugh I don't want to them not be for sale, but that doesn't mean that I necessarily want to be the one to sell them.

    My big driver is that they're darned expensive to get manufactured in small quantities (like $100 for 1, $85 for 2), but they're affordable if you make several hundred (~$30). I want to be able to buy several for my own use, and I want to hardware design to be open, so I'd be delighted if there were a group buy that made it cheaper for me.

    The catch is that, well, I already have a job. I don't really want a second job. Manufacturing these and selling them sounds like a second job. An ideal situation for me would be if some company wanted to take care of all of the annoying business details, run a group buy, and I got the boards I wanted cheaper (Here's looking at you, Onion Corporation!).

    If someone knows of an assembly house that makes things like this easy, speak up. I'm getting my first ones assembled by Macrofab, but if there's enough interest, I will probably check out a place like CircuitHub or Seeed Studio.

    Anyone have any other recommendations?

    That said, this will all have to wait for my first four to arrive, so I can find out if I've totally botched the design or not.

    1
  • S

    @Freddy-Franco @Bas-Rijniersce

    Ah yes, Ubiquity! There's a company who's too cool to follow standards! Don't get me wrong, I'm sure they have their reasons, and some of their gear will operate on 24V non-standard PoE and/or 48V standard PoE.

    I'm pretty sure it can be made to work for 24V, although the design might need some tweaking to make everything happy. In the very least, the under-voltage lock-out is set to 35 V, so at least one resistor would have to be swapped out. There might be more complications where we have to do something special to tell the IC that it's not in 802.3af negotiation mode, but I'll test it here when I get my first boards.

    0
  • S

    @Freddy-Franco I usually try to run off a PDF schematic, but I forgot. Here they are now. There's a board top-layer PDF in there too, but it's a mess to look at. Sometimes there's no substitute for opening the board layout in KiCad.

    0
  • S

    @Mark-Martin No, just passing the existing Ethernet PHY through. Ethernet PHY's are best connected to dedicated MAC hardware in the host processor, and there's no such spare hardware exposed on the Omega for that. To have a second Ethernet jack would take an SPI-to-Ethernet MAC+PHY or a USB Ethernet adapter, and that would be a total mess (I'm talking about you, Raspberry Pi Zeros!)

    This does mean that the Ethernet expansion board won't work, but, well, I think that's fair. The four Ethernet pins on the expansion header have been replaced with four spare IOs instead.

    0
  • B

    I'm very interested in this. I have current generation Ubiquiti UniFi gear which is 802.3af/at compliant. If it works with that, I would possibly buy several of these.

    0
  • V

    Really cool! This was a feature i was asked a lot for my dock\new, but i've never implemented it. I'll be more than happy to link this project.
    Let us know how the project goes 🙂

    BTW i can't open the project in my kicad version. Are you on a nightly build?

    0 S 1 Reply
  • S

    @valerionew I'm running Kicad out of an Ubuntu repository, 201801141617+0ee38bc~61~ubuntu17.0. Sorry that it's caused headaches - if you really care, I can try to get it running in a real released version. I think there's some turmoil as they prep for the KiCad 5.0 release. I'm holding off on submitting schematic and footprint library changes until that's all done, for example.

    That said, I can also post PDF's of layers or a BOM if you'd like. I'm just worried that someone will point out some fatal design flaw after I've ordered boards. 🙂

    0
  • R

    This is great! I have a dream about making a dock with PoE and the GSM-modem but understanding KiCad is my biggest hurdle!

    But this card looks great, i so want one! 🙂 Great work!

    0
  • E

    @Scott-G

    I might be interested. Depends on how testing goes

    0
  • K

    @Scott-G / @Eric-Walker
    me too

    0
  • S

    Woohoo! It works!
    Working board

    A few more images at https://github.com/zeroping/OmegaPoE.

    Known issues to work on:

    • I got one resistor wrong (560 kohm != 560 ohm)
    • I need a pull-down on the line that enables the 12V output - right now, it's on at boot
    • The flyback converter has some instability that I don't like, and it happens to be at ~16 kHz, which means you can hear it. I want to get to the bottom of that.
    • I want to test it with some stacking headers, rather than direct-soldering like the first one
    • I want to see if I can modify a devicetree to set up the Ethernet LEDs and tactile switch correctly

    But hey, I now have the silliest Ethernet-controlled light:

    https://photos.app.goo.gl/YS3vjE3wA9x9WqXG7

    3 P 1 Reply
  • P

    @Scott-G Nice work!

    Can you elaborate at all on your ethernet magjack LEDs? Am I correct to assume that they're functioning properly for 'link' and 'data'? How is that set up & configured on the Onion?

    1 S 1 Reply
  • S

    @peanut Oh, they're not connected in any fancy way at all. Since the Omega has the PHY, and since there's no broken-out pins specifically for the LEDs, I wired them up to GPIO15 and GPIO16. They function in that I can light them up by flipping them high as GPIO's, but I haven't gone farther than that yet.

    My understanding is that I can tweak the device tree a bit to say "No, this isn't a GPIO pin, it's an LED that is controlled by a GPIO" and then "This isn't just an LED, it's an LED that needs to be connected to an LED trigger that comes from the eth0 link status". The kernel handles it from there.

    There are LED's in many routers connected in the same way, it's just a matter of messing with it, and since the DTB appears to be baked into the firmware, I think that means rebuilding the firmware. Pretty low on the list of things to do at the moment.

    In case you're wondering, there are two other LEDs. One is just a general-purpose indicator. The other comes on when the 12V output MOSFET is turned on. I left that one unpopulated, but I had a little room there, and wanted to play with a reverse-mounted LED shining through the FR-4 circuit board. If you look carefully, there's text in the layers of the board, which should get silhouetted by the LED.

    Place on Github that has schematic PDF (and I don't know why I can't direct-link to the PDF)

    1 P 1 Reply
  • P

    @Scott-G Thanks for the feedback. I'd love to have the LEDs tied deep in to the kernel for 'link' and 'data' but I agree it'd be a lot of work. Neat project, thanks for sharing.

    0 S 1 Reply
  • S

    Alright, just a little more of a status update:

    The boards are working great! The 12V output works for running ~12 watts of strip LED, and the Omega can control it as expected. The 5V and 3.3V lines look great, even with some load, and the Omega's running without any issues. The whole thing is even pretty efficient - with a strip of LEDs, the Omega is putting out more heat than the converter.

    There was a bit of a hiccup where I failed to recalculate a resistor value when I scaled the design from 3.3V output to 12V output. That was throwing the compensation loop out of whack, causing the 16 KHz ringing. After a bit of learning about feedback compensation and some circuit modeling, I calculated the correct value, and it's much happier now - no more audible whine, no more 16 KHz ripple in the 12V line. I'm now willing to declare that this design works!

    I've even fixed the rest of my boards. Aside from the first one, which gave it's life for that resistor value fix, the other three work great.

    I'm eager to go make something cool with this set up, but I know I got some people interested in a group buy. If I'm going to make that happen, I have a few questions for everyone:

    • I've soldered the Omega down to my boards, but it should also be possible to put 2mm headers under them. Digikey is currently out of stock of the headers that are known to work, but I have some alternatives coming in a few days. The headers are only a few bucks, and only add ~4mmm of height. How many people would prefer to solder their Omega's down permanently?
    • There's always going to be some ripple in the 12V line when it's under full 15W load - how much ripple is acceptable to you? I'm aiming for <150 mV, but I'm going to have to add a capacitor to get that. Am I the only one who cares? I might just leave an unpopulated pad for people to add a capacitor if they need it.
    • We could save a few bucks if we decided
    • I have the 12V output header controlled by a MOSFET, controlled by a GPIO. That GPIO, however, floats on startup, causing the 12V output header to be unpredictable. I want to add a resistor to hold it either high or low during power-up. So, 12V on by default, or off?
    • If I run a group buy of these, how many are people interested in? They get cheaper the more that I order at once. $100 for 1, $78 for 4, $65@10, $60@40, $45@100 (approximate)... What kind of price range would people be interested in? How many?

    P.S.: If anyone who works for Onion is reading, and wants to order and sell these so that I don't have to, that would be great! I'd love for my design to be the official PoE dock, and I wouldn't mind avoiding the trouble of running a group buy.

    0
  • S

    @peanut I got the Ethernet jack LEDs working.
    relevant thread here

    The specific bit of device-tree magic was to add my new gpio-leds:

    gpio-leds {
	compatible = "gpio-leds";
	system_led: system {
		gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
	};
       user_led: user {
		gpios = <&gpio0 0x11 GPIO_ACTIVE_LOW>;
	};
       eth_y_led: eth_y_led {
		gpios = <&gpio0 0x10 GPIO_ACTIVE_HIGH>;
	};
       eth_g_led: eth_g_led {
		gpios = <&gpio0 0x0F GPIO_ACTIVE_HIGH>;
	};
};

    Note that they're on GPIO0.

    And something like this:

    echo netdev > /sys/class/leds/eth_y_led/trigger
echo eth0 >/sys/class/leds/eth_y_led/device_name
echo "link tx rx" >/sys/class/leds/eth_y_led/mode
echo 20 >/sys/class/leds/eth_y_led/interval

    That said, it wasn't really worth it 😞

    After I got it working, I realized that the only thing it could tell me is that there were packets. The most important part of link lights is usually to know that there's link, but it's pretty unusual (but not impossible) to get Power over Ethernet without also getting, well, Ethernet. This means that on my PoE board, the Ethernet link light is only very slightly different than a power LED, which we already have. And until I get default values into the device tree, it doesn't come up until I turn it on from userspace anyways.

    Still, it's nice to know how to turn GPIOs into LEDs, allowing a wide range of triggers. If this thing were in a box, I might use those ethernal Ethernet link LEDs as a heartbeat, or as an disk activity indicator.

    0
  • B

    I am building a Hub that supports POE as well. The circuit I am using supports 12-48v DC (dont want to deal with diode rectifier for AC) POE injectors. I am actually using Ubiquity as one of the POE testers.

    You have a lot more passive components than I do. Mine only uses 12 BOM line items. (14) total. Maybe because my Ethernet Jack has the Harmonics built in. Either way, good work.

    0 S 1 Reply
ethernet 63 dock 26 poe 5 open hardware 1 802.3af 1
Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.