element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      • Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum Self-powered hub + RF mouse + network = Fail
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 30 replies
  • Subscribers 678 subscribers
  • Views 4527 views
  • Users 0 members are here
Related

Self-powered hub + RF mouse + network = Fail

morgaine
morgaine over 13 years ago

Over the last several days, I've been doing a lot of testing of Pi with self-powered USB hubs.  Of the 3 hubs I possess, one is not Pi-compatible so I won't refer to it any further here.  The other two are nominally Pi-compatible and USB-compliant (they don't supply power upstream through the A-B lead), and the Pi boots fine with either of them connected, even when its power comes from one of their ports.  They are well-known and moderately expensive 4 and 7-port Belkin hubs, powered with hefty 2.5A and 3.8A mains adapters respectively:

 

  • Belkin TetraHub Hi-Speed USB 2.0 (4-Port) Hub F5U231
  • Belkin USB 2.0 Plus (7 Port) Hub F5U307

 

The testing had a single goal, to get the Pi to work correctly with 2 common USB devices attached to the self-powered hub, a mouse and a keyboard, while at the same time being connected to my local wired network.  The definition of "work correctly" for these tests was "A. Not lose any USB events" and "B. Operate normally over the local LAN without RTT anomalies nor packet loss".  Nobody could call this requirement ambitious --- it's the minimum one could demand of a networked computer today, or even less than minimum since the tests involved no thumb drive for backup for example.  (Such expansion is the reason for the hub.)

 

Soon after receiving my Pi I reported here about the substantial USB event/data loss I was seeing, which made the Pi barely usable for me.  (No USB hubs were connected at the time).  I found a wired mouse and keyboard that worked with only occasional dropouts so the Pi became more or less operational, but I had no time to pursue the USB loss issue further, until now.  "More or less operational" means I wasn't cursing too frequently, despite the losses.

 

Tethered keyboards aren't too bad for me because the keyboard rarely moves around, but I find tethered mice a poor human interface as the wire just gets in the way.  Therefore my main focus was to find an RF mouse that works with the Pi in the above configuration, and I planned to check out RF keyboards only later.  I have 6 RF mice of 4 different types:

 

  • Logitech MX-1000
  • Logitech MK320 Desktop combo (mouse only)
  • Logitech EX110 Desktop combo (mouse only)
  • Sandstrom SMWLL11

 

I won't list my wired keyboards nor wired mice for the simple reason that they all work "mostly OK" both when plugged into the Pi's on-board USB sockets and also when plugged into the self-powered hubs --- they're a combination of Logitech, Dell, and unbranded others.  "Mostly OK" means that there is an occasional USB event lost, but other than that, they fall into my "more or less operational" category.  (Not really satisfactory, but then, this is the Pi ...)

 

To avoid this post getting too long, I'm going to summarize my results ruthlessly, because despite a little variation, they all fall into the same ballpark:

 

  • If any of the above RF mice is plugged into either of the above self-powered hubs, then USB event/data loss increases from minimal to massive, USB response often disappears altogether for 5-10 seconds at a time (both mouse and keyboard), network ping RTT changes from a nominal 0.5 ms to thousands of times longer (1-13 seconds),  Ethernet controller read and write failures appear repeatedly in /var/log/messages, and all higher-level network activity such as ssh or NFS ceases or fails.
  • Replacing the RF mouse by a wired one usually ends the problem and returns the system to normal (but not perfect) operation.  Sometimes, unplugging the RF mouse is not enough and the hub needs to be unplugged from the Pi and replugged, which almost always ends the problem as long as no RF mouse is connected.  A couple of times I also had to reboot to recover.

 

This difference between RF and wired mice is so striking and so unambiguous that I'll just leave it at that.

 

From my experience, the Pi is not usable with RF mice attached to self-powered hubs, if my hubs are representative.

 

These tests were carried out with Raspbian updated to the latest packages and RPF firmware.

 

Morgaine.

  • Sign in to reply
  • Cancel
Parents
  • Former Member
    Former Member over 13 years ago

    Morgaine,

     

    I am curious on one point. The first "powered" hub I purchased was actually the Belkin 7-Port Powered Hub Model F5U307.

     

    If I understood your earlier posts correctly, this device worked with RPi for you.

    Sadly not for me.

    I rather had my doubts if the supplied PSU is really capable of supplying 5V at 3.5 ... 3.8 amp as claimed.

    I asked one hardware expert friend to test the real capability of the Belkin PSU, but dont have the results just yet.

     

    I also reported back to Farnell that their advertised Raspberry Pi "Powered" 7-Port USB Hub "Dynamode" USB-H70-1A-2.0

    does not work for me with RPi. They committed to look at the issue, which is promising.

     

    I feel very dubious whether investing in yet another "powered" hub will result in a success. The cost as such is not the main problem.

    You seem to have analysed very extensively this USB issue. Is this a totally lost cause with RPi or is there reliable confirmation which

    "powered" USB HUBS _really_ do work successfully with RPi ?

     

    I am very keen on RPi, so the USB Hub issues have been quite disappointing.

     

    Best Regards Colum

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • morgaine
    morgaine over 13 years ago in reply to Former Member

    Colum Gaynor wrote:

     

    I am curious on one point. The first "powered" hub I purchased was actually the Belkin 7-Port Powered Hub Model F5U307.

     

    If I understood your earlier posts correctly, this device worked with RPi for you.

    Sadly not for me.

     

    Oh dear.  image

     

    Yes I can confirm that the F5U307 worked fine with my Pi, in the limited sense that the Pi boots up fully when it's properly powered and while the hub's upstream port is connected to one of the Pi's USB host ports.  What's more, the Pi boots up fully even when its power is supplied by this same self-powered hub through a type-A to micro-USB lead, rather than from my usual 1A USB charger.  And the same is true of the 4-port Belkin hub that I mentioned, which is currently in use with the Pi.

     

    When I say "works fine in the limited sense", I mean that despite the successful boot, I still get regular but occasional USB data loss on the wired keyboard and wired mouse, but I do not get the complete non-working disaster that occurs when I plug in an RF mouse into either of those two hubs.

     

    If your F5U307 doesn't work then my first inclination would be to follow John's advice above.  If you manage to completely eliminate power supply problems though, then this becomes very curious indeed.  I see only three possibilities if it's not a power issue and you have no USB devices plugged into the hub and it still fails to boot:

     

    1. We are running different RPF firmware or kernels, which differ in USB fault behavior.
    2. There are additional fault scenarios with Pi power or USB that we don't currently know.
    3. Our Pi's are possessed, but I live further from the Hellmouth. image

     

    Let's eliminate point 1.  I am still running the same system now that I was running for the experiments, so here are the details:

     

    $ uname -a

    Linux pi 3.1.9+ #272 PREEMPT Tue Aug 7 22:51:44 BST 2012 armv6l GNU/Linux

     

    $ /opt/vc/bin/vcgencmd version

    Aug  8 2012 22:54:59

    Copyright (c) 2012 Broadcom

    version 330232 (release)

     

    $ grep MemTotal /proc/meminfo

    MemTotal:         188112 kB

    # So it's the 192M split

     

    $ lsusb

    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.

    Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.

    Bus 001 Device 004: ID 050d:0231 Belkin Components

    Bus 001 Device 005: ID 413c:3016 Dell Computer Corp. Optical 5-Button Wheel Mouse

    Bus 001 Device 007: ID 046e:5109 Behavior Tech. Computer Corp.

    #

    # My F5U307 is currently in use elsewhere and the 4-port F5U231 is connected to Pi:

    # The only difference visible in a plain 'lsusb'  is ID 050d:0307 vs 050d:0231.

    # The mouse and keyboard shown are both wired and connected to the F5U231.

     

    (root)$ lsusb -v  |  grep -iP "Transfer Type.*(Interrupt|Isochronous)"  |  wc -l

    9

    # These 9 matching endpoints are all of type:

    #     Transfer Type          Interrupt

    #

     

    Any differences thus far between our systems?

     

    Morgaine.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to morgaine

    Thanks Morgaine, Away from base but will investigate based on your advice and reply back soon. Thanks for valuable ideas and help.

    -Colum

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • morgaine
    morgaine over 13 years ago in reply to Former Member

    Likewise, I'll report back when I've upgraded the RPF firmware and kernel.  'Might have time this weekend.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to morgaine

    Attempt #3 to add message reply with readable formats... image

     

    Apologies to you both (proving Morgain & John Beetem) for the long silence and inactivity.

    I am now finally back at base, and have even thrown some more hard won 'dosh' at

    the problem(i.e. to provide meaningful answers to John's question on my voltage

    quality I went out and invested in a nice compact Digital Multi-Meter) and can provide

    some new facts and -even- some success!

     

    First: John, as you no doubt deeply suspected: YES - clearly I am suffering from dodgy

    +5V voltage levels. To be precise, I am powering the RPi from Nokia Lumia 800 USB

    charger (model AC-16E), which is rated for 5v output at 1 amp. With a variety of

    configurations (HUB in use, no HUB in use, USB devices plugged out from RPi, USB devices

    plugged in to RPi etc),the voltage between test points TP1 - TP2 is 4.75V. Although

    this strictly complies to your recommended stipulation of 5V +/- 5%, it falls below

    your preferred minimum level of 4.8V. I have ordered from Farnell Element 14 a PSU

    advertised in their accessory page, but delivery of EURO standard pin configuration

    is estimated for year 2013. NOTE that the Nokia AC-16E is in the list of known to

    work USB chargers for RPi, and -as I will report further below- my RPi is actually

    working with it; despite the non-ideal voltage level of 4.75V.

     

    Second: You mentioned 'iffy' Micro USB Cables. Again you are correct there. The open

    circuit voltage measured at the USB A connector of the AC-16E, with no USB cable

    attached is 5.3V. Attach the Nokia supplied Micro USB cable and allowing a load to

    be drawn, the voltage is as stated above 4.75V. If I replace the Nokia supplied micro

    USB cable with a Micro USB cable ordered from Farnell Element 14 in their RPi

    recommended accessories web page (Farnell Part #: 2115733, Product description:

    RPUSB1.8 CABLE, USB A M - MICRO B M, 1.8M 85444290, Mnfr Part # RPUSB1.8), the

    measured in circuit, powered up RPi accross TP1 - TP2 drops to about 4.65V.

    Somewhat disappointed, but understandable since the length of the Farnell supplied

    cable is 1.8 metres but the Nokia supplied cable is less half of that length).

     

    Conclusion: I need to get a +5V regulated power supply which can source 2 amps

    for good measure. It's proving a bit tricky item to source here in Finland, but

    hopefully soon I will find one.

     

    About the LEDS : I will report on those in the latest report of using Belkin USB

    HUB F5U307 below.

     

    Now, on to Morgaine's questions, but I need to clear up one misunderstanding first.

    When I reported that the Belkin F5U307 did not work for me, I should have been more

    precise. It has always worked in the sense that with a mini USB keyboard and USB

    cabled optical mouse attached to the Belkin USB hub F5U307 connected to RPi, the RPi

    always booted ok and the devices were usable. The problems however arose when I tried

    (in many different combinations) to plug in additional USB devices, either to free

    ports on the HUB, or using the spare USB port of the RPi. I was never able to get more

    than two devices to work concurrently, which rather defeated the whole purpose of buying

    a powered hub. The fact that the WiFi Dongle (Siemens Gigaset USB Adapter 300) did not

    work was somehow expected, as there are many reported issues with current hungry WiFi

    dongles in the RPi forum. I did, however, expect that the USB Stick memories I was test-

    ing would at least work witht the Belkin USB Hub. At the time of first testing back in

    July 2012, I could not succeed to get them to work whenever the number of USB devices

    exceeded 2. (The same Belkin USB HUB worked fine when tested with my LG model LGF1

    Laptop PC running Ubuntu 12.04 LTS).

     

    I can happily report that your tip #1. helped:

      "1. We are running different RPF firmware or kernels, which differ in USB fault

          behavior."

     

    You advised me to run some commands and compare the results with your offered output:

     

        $ uname -a

        Your result: Linux          pi 3.1.9+ #272 PREEMPT Tue Aug  7 22:51:44 BST 2012 armv6l GNU/Linux

        My result:   Linux raspberrypi 3.1.9+ #168 PREEMPT Sat Jul 14 18:56:31 BST 2012 armv6l GNU/Linux

     

        ---> I was clearly running older version of software than you. I have now learned how to

             use the HEXXEH RPi Update tool and performed an update a little while back.

     

        My current result is now:

        Linux raspberrypi 3.2.27+ #60 PREEMPT Thu Aug 23 15:33:51 BST 2012 armv6l GNU/Linux

        ---> My current tests are done with slightly newer software, compared your listed versions.

       ____________________________________________________________________________________________

     

        $ /opt/vc/bin/vcgencmd version

        Your result:    Aug  8 2012 22:54:59

                        Copyright (c) 2012 Broadcom

                        version 330232 (release)

        My result:      Jul 14 2012 13:11:40

                        Copyright (c) 2012 Broadcom

                        version 325444 (release)

     

        ---> Again, I was clearly running older version of ?firmware? than you.

             After the successful rpi update with HEXXEH tool my current version is now:

     

        My current result is now:

        Aug 23 2012 15:36:01       

        Copyright (c) 2012 Broadcom

        version 332937 (release)

        ---> Again,my current tests are now done with slightly newer ?firmware?, compared

             your listed versions.

        __________________________________________________________________

     

        $ grep MemTotal /proc/meminfo

        Your result: MemTotal:         188112 kB

                     # So it's the 192M split

        My result:   MemTotal:         220432 kB

        ---> So we have different memory split

             Sorry, not sure if things work better for me with your

             memory split, and I dont really know yet how to change the

             memory split. I used the defaults with the Raspbian Wheezy image

        __________________________________________________________________

     

        $ lsusb

        Your result:

        Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

        Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.

        Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.

        Bus 001 Device 004: ID 050d:0231 Belkin Components

        Bus 001 Device 005: ID 413c:3016 Dell Computer Corp. Optical 5-Button Wheel Mouse

        Bus 001 Device 007: ID 046e:5109 Behavior Tech. Computer Corp.

       

        My result:

        Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

        Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.

        Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.

        Bus 001 Device 004: ID 050d:0307 Belkin Components USB 2.0 - 7 ports Hub [FSU307]

        Bus 001 Device 013: ID 0951:160f Kingston Technology

        Bus 001 Device 006: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty

        Bus 001 Device 007: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse

        Bus 001 Device 011: ID 0781:5530 SanDisk Corp. Cruzer

        Bus 001 Device 014: ID 046d:0a01 Logitech, Inc. USB Headset

     

        You commented:

        #

        # My F5U307 is currently in use elsewhere and the 4-port F5U231 is connected to Pi:

        # The only difference visible in a plain 'lsusb'  is ID 050d:0307 vs 050d:0231.

        # The mouse and keyboard shown are both wired and connected to the F5U231.

       

        ---> The output from my RPi matches your expected result!

             NOTE: In addition to wired mini USB Keyboard (Farnell recommended RPi accessory)

                   and wired optical USB mouse, I also have a Kingston DT Mini 4Gb USB memory

                   stick and SanDisk 32Gbyte Cruzer USB memory stick inserted. All devices are

                   working. I was also able to insert a fifth device a Logitech USB Headset

                   and managed to get it (sporadically) to work with VLC Media program, which

                   I installed. I streamed one Internet Radio Station with MP3 56kbit/S and got

                   some sound, but the VLD Media did not behave very reliably...

        __________________________________________________________________

     

     

        (root)$ lsusb -v  |  grep -iP "Transfer Type.*(Interrupt|Isochronous)"  |  wc -l

        9

        # These 9 matching endpoints are all of type:

        #     Transfer Type          Interrupt

        #

     

        ---> For my system, the returned result was 12 endpoints.

        __________________________________________________________________

     

     

        Unfortunately, I still get many issues, whenever I try to connect the WiFi dongle,

        but these latest successes get me now a good deal further. By the way, although the

        PSU supplied with the Belkin F5U307 7-Port USB Powered HUB claims to be able to source

        +5V at 3.8amp, the small physical size of unit is such that I simply doubt it can meet

        the claimed specification.

     

        Anyway, thanks again your tips and the WiFi Dongle is the next challenge to crack.

     

        Regards Colum

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    And about the LEDS. (Sorry I forgot them in the earlier too long anyway reply).

    In the current configuration with Belkin F5U307 Powered USB Hub attached to one USB port of the RPi (other USB port is free) and wired ethernet connection (100Mb/s) via my Wireles Router 4 back panel Ethernet RJ45 eternet ports, the following LED behaviour is observed:

     

    Led Name  Colour   Observed Behaviour

    OK             Green     Mostly OFF but transient short bursts of ON activity

    PWR          Red       Permanently ON

    FDX           Green     Permanenty ON

    LNK           Green     Flashing evenly ON and OFF at about 2 Hertz

    10M           Yellow     Permanently ON

     

    Regards Colum

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • johnbeetem
    johnbeetem over 13 years ago in reply to Former Member

    Thank you for the details!  This helps everyone get a better picture of what's going on with RasPis.

     

    Colum Gaynor wrote:

     

    First: John, as you no doubt deeply suspected: YES - clearly I am suffering from dodgy

    +5V voltage levels. To be precise, I am powering the RPi from Nokia Lumia 800 USB

    charger (model AC-16E), which is rated for 5v output at 1 amp. With a variety of

    configurations (HUB in use, no HUB in use, USB devices plugged out from RPi, USB devices

    plugged in to RPi etc),the voltage between test points TP1 - TP2 is 4.75V. Although

    this strictly complies to your recommended stipulation of 5V +/- 5%, it falls below

    your preferred minimum level of 4.8V. I have ordered from Farnell Element 14 a PSU

    advertised in their accessory page, but delivery of EURO standard pin configuration

    is estimated for year 2013. NOTE that the Nokia AC-16E is in the list of known to

    work USB chargers for RPi, and -as I will report further below- my RPi is actually

    working with it; despite the non-ideal voltage level of 4.75V.

     

    Second: You mentioned 'iffy' Micro USB Cables. Again you are correct there. The open

    circuit voltage measured at the USB A connector of the AC-16E, with no USB cable

    attached is 5.3V. Attach the Nokia supplied Micro USB cable and allowing a load to

    be drawn, the voltage is as stated above 4.75V. If I replace the Nokia supplied micro

    USB cable with a Micro USB cable ordered from Farnell Element 14 in their RPi

    recommended accessories web page (Farnell Part #: 2115733, Product description:

    RPUSB1.8 CABLE, USB A M - MICRO B M, 1.8M 85444290, Mnfr Part # RPUSB1.8), the

    measured in circuit, powered up RPi accross TP1 - TP2 drops to about 4.65V.

    Somewhat disappointed, but understandable since the length of the Farnell supplied

    cable is 1.8 metres but the Nokia supplied cable is less half of that length).

     

    Conclusion: I need to get a +5V regulated power supply which can source 2 amps

    for good measure. It's proving a bit tricky item to source here in Finland, but

    hopefully soon I will find one.

    If RasPi works at 4.75V, there's really no need to go higher.  My own RasPi works at 4.65V -- below that the display starts to act up.  A lower TP1-TP2 is going to have a much larger effect on peripherals.  If your peripherals are 3.3V internally, a lower TP1-TP2 will simply make life easier for their regulators.  OTOH, if a peripheral really needs 4.75V to operate reliably, then you do need to be concerned about TP1-TP2.

     

    It sounds like your main problem is the Micro USB cable.  It's disturbing that the Farnell recommended accessory has such a large voltage drop, but not surprising for a 1.8 m cable.  The problem is that many Micro USB cables have very thin wires, which work OK for data (as long as you don't flex the cable too many times) but are inadequate for 1 A power currents.  It's usually impossible to tell what wire gauge you're going to get from mail-order cables.

     

    A larger power supply isn't going to help if your problem is the cable.  If RasPi only needs 700 mA, it will only draw 700 mA over the cable whether the power supply is capable of delivering 1A or 2A.  The voltage drop is determined by the resistance of the cable and is independent of the power supply's max current.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • johnbeetem
    johnbeetem over 13 years ago in reply to Former Member

    Colum Gaynor wrote:

     

    And about the LEDS. (Sorry I forgot them in the earlier too long anyway reply).

    In the current configuration with Belkin F5U307 Powered USB Hub attached to one USB port of the RPi (other USB port is free) and wired ethernet connection (100Mb/s) via my Wireles Router 4 back panel Ethernet RJ45 eternet ports, the following LED behaviour is observed:

     

    Led Name  Colour   Observed Behaviour

    OK             Green     Mostly OFF but transient short bursts of ON activity

    PWR          Red       Permanently ON

    FDX           Green     Permanenty ON

    LNK           Green     Flashing evenly ON and OFF at about 2 Hertz

    10M           Yellow     Permanently ON

     

    Regards Colum

    If I understand your comment correctly, you have RasPi's RJ45 Ethernet port connected with an Ethernet cable to your router.  The LNK LED should not be blinking on and off -- a LNK LED normally turns on within a second of connecting the cable and stays on as long as the cable is connected and your router is running.  However, maybe RasPi does something different from the usual behavior.  Are you seeing the same behavior at the router, or is its LNK LED for the RasPi port steady?

     

    Is RasPi able to ping the router reliably?  "ping" is a very useful command for diagnosing IP network problems -- enter "man ping" for options.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to johnbeetem

    CG: Yes, you are quite right about the root of the problem with respect to Micro USB cable.

           Ohms law cannot be beaten!

          

            The LED behaviour re-examined quickly.

            The flashing LNK Green LED behaviour is confirms and the corresponding link LED on the Router also display a transient flashing behaviour...

            However, I realised that I have had VNC remote session from my Ubuntu Laptop into the Pi ( Ubuntu has wireless connection to same router )

            and if I kill that VNC session, the LNK LED goes mostly steady, unless I activate the Midori browser locally on the RPi.

          

            Tried a ping from the RPi to the Laptop via the router and it works !

            Sorry, I am not able to explain it but looks like when there is activity on the wired ethernet circuit of the RPi then transient flashing of the LNK

            LED is seen. It's not quite even (i.e. the LED is ON asymmetrically longer compared the LED OFF periods).

     

            Midori sessions work find both from local RPi session and from Ubuntu Laptop via remote VNC session to RPi.

     

            Regards Colum

     

            PS Received my "Pimoroni" plastic case for RPi finally, so the weekend's task is mechanical this time !

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • Former Member
    Former Member over 13 years ago in reply to johnbeetem

    CG: Yes, you are quite right about the root of the problem with respect to Micro USB cable.

           Ohms law cannot be beaten!

          

            The LED behaviour re-examined quickly.

            The flashing LNK Green LED behaviour is confirms and the corresponding link LED on the Router also display a transient flashing behaviour...

            However, I realised that I have had VNC remote session from my Ubuntu Laptop into the Pi ( Ubuntu has wireless connection to same router )

            and if I kill that VNC session, the LNK LED goes mostly steady, unless I activate the Midori browser locally on the RPi.

          

            Tried a ping from the RPi to the Laptop via the router and it works !

            Sorry, I am not able to explain it but looks like when there is activity on the wired ethernet circuit of the RPi then transient flashing of the LNK

            LED is seen. It's not quite even (i.e. the LED is ON asymmetrically longer compared the LED OFF periods).

     

            Midori sessions work find both from local RPi session and from Ubuntu Laptop via remote VNC session to RPi.

     

            Regards Colum

     

            PS Received my "Pimoroni" plastic case for RPi finally, so the weekend's task is mechanical this time !

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
  • johnbeetem
    johnbeetem over 13 years ago in reply to Former Member

    Colum Gaynor wrote:

     

            The flashing LNK Green LED behaviour is confirms and the corresponding link LED on the Router also display a transient flashing behaviour...

            However, I realised that I have had VNC remote session from my Ubuntu Laptop into the Pi ( Ubuntu has wireless connection to same router )

            and if I kill that VNC session, the LNK LED goes mostly steady, unless I activate the Midori browser locally on the RPi.

     

            Tried a ping from the RPi to the Laptop via the router and it works !

            Sorry, I am not able to explain it but looks like when there is activity on the wired ethernet circuit of the RPi then transient flashing of the LNK

            LED is seen. It's not quite even (i.e. the LED is ON asymmetrically longer compared the LED OFF periods).

    According to the RasPi Hardware Wiki, the LNK LED is actually a Link/Activity LED, so the behavior you're seeing is correct.  A Link/Activity LED is on when link has been established and flickers when there is receive and/or transmit activity.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube