Alas this combination doesnât work, power is supplied and the Shake is happy but no Ethernet link is established. I say the Shake is happy because if I power it from the PoE and plug in a direct network cable then the Ethernet port Tx/Rx lights spring into action and all is well, whereas previously the lights were unlit. However I have seen for a brief 0.5 seconds the ports lights come to life and the Shake responds to pings but then the lights go dark. Have of course tried various cables, different lengths and Cat 5E / 6E.
Donât have the spares to try and determine if itâs a sender, receiver or both problem.
Anyone have a working Raspberry Pi 4 Model B and RSBOOM PoE solution?
You can supply 12 V by Ethernet and near RS you put a pasibe inyector with a DC-DC step down converter to 5.1 V.
(REF: Structural health monitoring of South Americaâs first 6-Story experimental light-frame timber-building by using a low-cost RaspberryShake seismic instrumentation, Engineering Structures, Volumen 275, Part B, January 2023)
Be careful with the thickness of the 5 V cables, they are usually of a section that does not support 3A, causing the RS to report power problem in /var/log/kern.log
This is very interesting, Hadders; keep us posted on your progress!
I think you may be the first (or one of the first) Shakers testing a PoE implementation with a Pi4 board, so what you find will be extremely useful to the community.
That looks like it should work. I would spend a bit of time finding out which part is not working (faulty).
It sounds as though you have validated that the power works correctly by directly connecting an ethernet cable, so it sounds like a problem with the ethernet connectivity in one or other of the devices.
Maybe try normal power then connect your known good and working ethernet cable into part 1 and then into the R-Pi - still works? Then that component is probably ok - if not, get Amazon to exchange it.
If all is ok with (1), then connect your ethernet cable to part 2, and from part 2 to the R-Pi (without powering it - it shouldnât need power for this test). Again if it works, it is probably ok, if not - Amazon exchang would be the next step.
Last step would be to connect (1) to (2) and see if there is connectivity - if each part worked, this should work. Assuming it does, apply power (no need to load it). Still works? Apply a load (Another R-Pi or similar).
Somewhere along this chain of testing you should be able to isolate the defective part âŚ
@PhilipPeake Tried some of these âIf all is ok with (1), then connect your ethernet cable to part 2, and from part 2 to the R-Pi (without powering it - it shouldnât need power for this test). Again if it works, it is probably ok, if not - Amazon exchang would be the next step.â Unfortunately I couldnât get a signal through without power which either means it needs power to passively pass the signal or this is a faulty unit.
Lots of unknowns to juggle & it could be both units are faulty or just not compatible with each other.
Shortest injector to splitter cable I tried was a 0.5m Cat 6 (possibly Cat 6a).
Managed to find a computer with a console and ability to connect over Ethernet.
To cut a long story short the problem seems to be with our old friend âauto-negotiationâ and / or duplex with the PTZlink injector, the REVODATA splitter seems to behave fine.
I worked with âethtoolâ on the console computer. On the Shake âethtoolâ is not installed, only âmii-toolâ. Not sure if itâs a good idea to install anything on the Shake?
Have yet to work out exactly whatâs going on but have ruled out the router, cables & type / lengths. Am beginning to think the PTZlink isnât suitable or is just faulty.
Considered adding in a â100baseT Fullâ line somewhere on the Shake using mii-tool, however Iâve seen the link drop during my tests (like when writing this message!) which again points to a problem with the injector so this might not the best fix.
Parking some notes here as an aide-mĂŠmoire. Note the âLink partner advertised link modeâ (PTZlink injector) doesnât even offer 1000baseT even though it is sold as a gigabit device.
$ sudo ethtool -s enxb6d397fe3496 advertise 0x008
0x001 10baseT Half
0x002 10baseT Full
0x004 100baseT Half
0x008 100baseT Full
0x010 1000baseT Half (not supported by IEEE standards)
0x020 1000baseT Full
$ ethtool enxb6d397fe3496 ; echo ; echo -n "Link speed: " ; cat /sys/class/net/enxb6d397fe3496/speed
Settings for enxb6d397fe3496:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Auto-negotiation: on
Port: MII
PHYAD: 3
Transceiver: internal
netlink error: Operation not permitted
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Link speed: 100
$
Interesting⌠I have to admit I was thinking of both components being passive. At least as far as the ethernet connectivity is concerned.
Having been bitten too many times by auto-negotiation, I have to admit that I generally fix the speeds of most of my things - particularly where any appreciable cable runs are involved. No matter what quality cable.
I had communications problems between one router and an RS4D. The problem was that the router used RJ45 pinout T-568A (Straight) and the RS4D needed with T-568B (crossover).
It could be the same problem
I only installed it this morning but the RSBOOM and Raspberry Pi 4 Model B are powered and networked. Occasionally there is small packt loss, about 0.1% which I donât think was there previously but this could also be because Iâve started dabbling with rsudp and added sending to a Datacast host (the âShake live real-time data streaming and archived data accessâ downtime did have an advantage giving me the push I needed). Iâll keep an eye on the whole system and see how it behaves over the next few weeks. I notice sometimes ping times go up to 271 ms from say 5 ms so one possibility could be the unit is jumping between IEEE 802.3af 802.3at if the power consumption is on the borderline. It could also be because the injector is a Ver: 2.0 rather than Ver: 2.6 or possibly because this is just what PoE does.
So now I have my router and distant RSBOOM on the same UPS. Happy days !
!