Home of the Squeezebox™ & Transporter® network music players.
Page 11 of 12 FirstFirst ... 9101112 LastLast
Results 101 to 110 of 118
  1. #101
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    548
    Quote Originally Posted by POMdev View Post
    I attached a three wire so-called 'TTL' level serial connection to the Squeezebox Radio ('SB'). I soldered to the battery connector,
    For those who might want a more permanent set up, battery connector matches JST PHD series. I found connector housing and pre-crimped tails at Conrad. Refer https://forums.slimdevices.com/showt...l=1#post978826

  2. #102
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,572
    Quote Originally Posted by POMdev View Post
    I'm not sure how udhcpc is launched, but it reports:
    The busybox builtin ifup script launches udhcpc in response to the udev network.sh script bringing up an interface.


    Quote Originally Posted by POMdev View Post
    (BTW, ^C (e.g., to stop ping) doesn't work in the serial console. The only way to break out is to reboot if you have lost your connection.)
    You can change /etc/inittab to enable job control on the serial port. See this post.

    The change is included in my recent firmware.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

  3. #103
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,572
    Quote Originally Posted by ralphy View Post
    The Cyanogenmod url looks promising. Thanks for that.

    I'll investigate building the ar6000 driver module from that source. Since it's loaded at boot time, we can replace the kernel module to try it without the need to flash a new firmware and a factory reset will revert the module to the stock version if things go badly.
    Unfortunately, the cyanogenmod ar6000 module v3.1.1.734 doesn't support the ar6002 in the radio...at least not my rev.7. Module loads on the radio but doesn't find the wifi hardware.

    Code:
    # cat /proc/cpuinfo | egrep '(Hardware|Revision)'
    Hardware	: Logitech MX25 Baby Board
    Revision	: 0007
    
    # cat /sys/class/mmc_host/mmc0/mmc0:0001/mmc0:0001:1/modalias 
    sdio:c00v0271d0201
    Code:
    ralphy@poky:~$ modinfo ~/source/squeezeos/poky/build/tmp-baby/work/baby-none-linux-gnueabi/atheros-ar6-module-src-3.1-r0/image/lib/atheros/ar6000.ko
    filename:       ar6000.ko
    license:        Dual BSD/GPL
    description:    Driver to access the AR600x Device, version 3.1.1.734
    author:         Qualcomm Atheros
    license:        Dual BSD/GPL
    description:    AR6K buffer pre-allocation
    author:         Qualcomm Atheros, Inc.
    alias:          sdio:c*v0271d0301*
    alias:          sdio:c*v0271d0300*
    depends:        
    vermagic:       2.6.26.8-rt16-dirty preempt mod_unload modversions ARMv5
    The only other ar6k module sources I've found are older .18 versus the .62 used for the radio.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

  4. #104
    Junior Member
    Join Date
    Aug 2020
    Posts
    13
    Thanks all for the very useful responses.

    I believe this "Radio Loses WiFi Connection" issue to be so serious as to deserve major escalation. My 6 radios are very nearly unusable, most failing after just a few minutes. Of course, not everyone is experiencing this yet, but enough have so far and the numbers likely will just keep growing. The entire ecosystem is threatened if the radios fail in large number.

    I tried turning everything off except for one new simple wireless AP, the main router, and the pc running LMS, including phones, cameras, televisions, IOT devices, and Bluetooth devices. Still, the radios wifi deteriorated and eventually lost connectivity. This suggests RFI of some sort disrupting the system, or that 6 radios on one access point is too many. However, these radios have been around for years, but this disconnection issue started only earlier this year, and has gotten worse during the summer.

    The neighbors are not that close, and their wifi signals are at least 20-30 db lower. I haven't gotten out the (quite heavy) spectrum analyzer yet to look for interference, but it looks like that might be necessary. I shouldn't need an LNA to detect what is presumably a high level signal.

    I tried setting the debugging flags, to increase the driver verbosity, but these had no effect (because the ar6000.ko driver was build without debug support?). However, a debug build may be needed.

    Despite time spent, I have not made much or any progress with this issue, being impeded by lack of the AR6102 chip specs and the source code (no access to this site's private repository.) The closest public source so far is some AR6kSDK.build_sw.18 code and various versions of AR6kSDK.3.1, some of which is close to but not the same as the code referenced in the various patch files. The various open source decompilers produce dubious looking gibberish.

    To reiterate, I see three issues: the device is too easily disrupted, fails to report a connection loss, and the supplicant or other layer does not otherwise notice a lack of connectivity and initiate corrective action. An optimum response would be to address all three.

    I examined the serial console log file started after over a day of disconnection. In this session, the radio is connected to a simple bgn router/access point located very close to the 4 of the 6 radios used by the 'important' (no, not me) users. The rssi of this access point at the test radio is 25 db below another modern AP 10 feet away. The bgn AP is on channel 1, which somehow greatly improved its chances of being detected by the ar6000 scan, and presumably connectivity, although not enough. Connected to the office AP, the SB radio is more stable. However, its UE office mate, 30 feet away from the same AP, drops out anyway after a few minutes, so rssi is not the only factor.

    The 'wpa_cli scan_results' frequently show only 1 to 3 access points, that is, the three nearby access points are frequently not all shown even though the signal strengths are all good to excellent. Occasionally, a neighbor's AP shows up, even though its signal strength is 20 db less than the lowest house AP. Also, the connected AP sometimes doesn't show up in the scan, a clue.

    I then switched each radio to the strongest AP signal, on the three APs, but they still kept dropping out after a few minutes, except the UE in the basement, and the one with the serial cable connection, which last much longer.

    Out of frustration, I concocted a script to ping the gateway, and reset the wireless when connectivity is lost. I cannot yet predict from the statistics (e.g., when the errors skyrocket and/or the data rates decline) when connectivity will be lost. So it's the ping method, which is reactive and result in an outage of several seconds. This should be handled by the supplicant, or other service, but since that is not working, this is a start.

    Some good news: "wpa_cli reassociate" restores connectivity in many, but not all, cases. It works fairly quickly, when it works.

    And, my script has been running on my 6 radios, and they are still connected, a big success!

  5. #105
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    4,996
    Quote Originally Posted by POMdev View Post
    Thanks all for the very useful responses.

    I believe this "Radio Loses WiFi Connection" issue to be so serious as to deserve major escalation. My 6 radios are very nearly unusable, most failing after just a few minutes. Of course, not everyone is experiencing this yet, but enough have so far and the numbers likely will just keep growing. The entire ecosystem is threatened if the radios fail in large number.

    I tried turning everything off except for one new simple wireless AP, the main router, and the pc running LMS, including phones, cameras, televisions, IOT devices, and Bluetooth devices. Still, the radios wifi deteriorated and eventually lost connectivity. This suggests RFI of some sort disrupting the system, or that 6 radios on one access point is too many. However, these radios have been around for years, but this disconnection issue started only earlier this year, and has gotten worse during the summer.

    The neighbors are not that close, and their wifi signals are at least 20-30 db lower. I haven't gotten out the (quite heavy) spectrum analyzer yet to look for interference, but it looks like that might be necessary. I shouldn't need an LNA to detect what is presumably a high level signal.

    I tried setting the debugging flags, to increase the driver verbosity, but these had no effect (because the ar6000.ko driver was build without debug support?). However, a debug build may be needed.

    Despite time spent, I have not made much or any progress with this issue, being impeded by lack of the AR6102 chip specs and the source code (no access to this site's private repository.) The closest public source so far is some AR6kSDK.build_sw.18 code and various versions of AR6kSDK.3.1, some of which is close to but not the same as the code referenced in the various patch files. The various open source decompilers produce dubious looking gibberish.

    To reiterate, I see three issues: the device is too easily disrupted, fails to report a connection loss, and the supplicant or other layer does not otherwise notice a lack of connectivity and initiate corrective action. An optimum response would be to address all three.

    I examined the serial console log file started after over a day of disconnection. In this session, the radio is connected to a simple bgn router/access point located very close to the 4 of the 6 radios used by the 'important' (no, not me) users. The rssi of this access point at the test radio is 25 db below another modern AP 10 feet away. The bgn AP is on channel 1, which somehow greatly improved its chances of being detected by the ar6000 scan, and presumably connectivity, although not enough. Connected to the office AP, the SB radio is more stable. However, its UE office mate, 30 feet away from the same AP, drops out anyway after a few minutes, so rssi is not the only factor.

    The 'wpa_cli scan_results' frequently show only 1 to 3 access points, that is, the three nearby access points are frequently not all shown even though the signal strengths are all good to excellent. Occasionally, a neighbor's AP shows up, even though its signal strength is 20 db less than the lowest house AP. Also, the connected AP sometimes doesn't show up in the scan, a clue.

    I then switched each radio to the strongest AP signal, on the three APs, but they still kept dropping out after a few minutes, except the UE in the basement, and the one with the serial cable connection, which last much longer.

    Out of frustration, I concocted a script to ping the gateway, and reset the wireless when connectivity is lost. I cannot yet predict from the statistics (e.g., when the errors skyrocket and/or the data rates decline) when connectivity will be lost. So it's the ping method, which is reactive and result in an outage of several seconds. This should be handled by the supplicant, or other service, but since that is not working, this is a start.

    Some good news: "wpa_cli reassociate" restores connectivity in many, but not all, cases. It works fairly quickly, when it works.

    And, my script has been running on my 6 radios, and they are still connected, a big success!
    The AR6102 datasheet is available here.

    https://datasheetspdf.com/mobile-datasheet/AR6102.html

    Sent from my Pixel 3a using Tapatalk

  6. #106
    Junior Member
    Join Date
    Aug 2020
    Posts
    13
    Quote Originally Posted by slartibartfast View Post
    The AR6102 datasheet is available here.
    https://datasheetspdf.com/mobile-datasheet/AR6102.html
    Thanks, I found that last week when looking for driver info. Unfortunately, it doesn't have enough detail, like register descriptions, etc., to be that useful. It does seem like a capable chip, so it looks like it could be made to work better than it is now. We don't hear any other complaints about that chip, which is another clue.

    Unfortunately, the cyanogenmod ar6000 module v3.1.1.734 doesn't support the ar6002 in the radio...at least not my rev.7. Module loads on the radio but doesn't find the wifi hardware.
    ...
    The only other ar6k module sources I've found are older .18 versus the .62 used for the radio.
    This is also what I found. However, this code does share similarities with the patch files, with the patches being a few to several lines off. Combined with RedDec and Radare2, etc., it might be possible to at least understand what might be happening.

    Interesting that AR6kSDK.build_3.1_RC.734 has open source "free software" statements as does .18, e.g.:

    * Copyright (c) 2004-2007 Atheros Communications Inc.
    * All rights reserved.
    *
    *
    * This program is free software; you can redistribute it and/or modify
    * it under the terms of the GNU General Public License version 2 as
    * published by the Free Software Foundation;
    *
    * Software distributed under the License is distributed on an "AS
    * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
    * implied. See the License for the specific language governing
    * rights and limitations under the License.


    The 3.1_RC.734 is similar. Would not this be the case with the .62 source, in the middle, as well? Perhaps someone could check the slimdevices private repository mentioned in the sources, and maybe make that public if so allowed. If not, it should be.

    Of course, the proprietary binary code and data for the processor might have problems. I wonder if it is Qualcomm Atheros's interests for this issue to grow, and whether that might make any difference regarding any support or access they might provide.

  7. #107
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,572
    Quote Originally Posted by POMdev View Post
    The 3.1_RC.734 is similar. Would not this be the case with the .62 source, in the middle, as well? Perhaps someone could check the slimdevices private repository mentioned in the sources, and maybe make that public if so allowed. If not, it should be.
    As the .62 and 3.1_RC.734 share one supported chipset sdio:c*v0271d0300 you could conclude that but the 020x support has been stripped or was never there.

    I've found what appears to be the source for .63 and most of the AR6kSDK.build_sw.62.baby.patch applies cleanly. Haven't had a chance to look at it more closely yet.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

  8. #108
    Junior Member
    Join Date
    Aug 2020
    Posts
    13

    Wireless Connectivity Mitigation Script

    I have put together a script to mitigate the radio wireless connectivity issue. I have been using versions of it for over 2 days now, and all 6 of my radios are connected. It works by restarting the wlan when it cannot ping the gateway for a period of time. It can be configured to send incident report messages to a logger on a reliable computer for analysis. Of course, these are sent only after re-connection, which has always occurred so far.

    If there is any interest, I can put the source on GitHub, or another service. This runs as an busybox ash script, so that others can examine, modify, improve, and adapt it to their needs. Mostly, I am interested in to what extent this software makes the radios more usable. I need more time listening instead of coding and documenting. It is important that the radios be enjoyable and not a source of frustration.

    I am hoping others can try the software and provide feedback, hopefully on this site, if that is appropriate.

    There were a lot of last minute changes as a result of the accompanying software documentation and to do list. Inevitably, this minimally- or un- tested software has bugs and other failings. Please let me know, and I will make a corrected version asap. In the meantime, if you can, fix it yourself, and keep going.

    The software consists of 2 scripts and 3 text documents. The "manual.txt" document has installation and usage instructions. I am attaching the "wlanpoke.0.4.1.zip" file in this message.

    After a period of initial review and revision, perhaps this software can be introduced to the user forums.

  9. #109
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    2,901
    Maybe someone can work out a way to turn it into a patch for the radio that can be installed via the built-in patch updater.
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  10. #110
    Junior Member
    Join Date
    Aug 2020
    Posts
    13

    New Script Version

    The script software has been running for three days now, with all 6 radios connected, except for a radio found powered off (power supply connector?) for an hour. Many have been continuously playing music without reported interruption (any interruptions were not noticed or reported).

    A bug in the previous version prevented uploading failure incidents to the logging server - oops, sorry. When fixing this error, it became opportune to add link quality statistics capture as a troubleshooting aid. I had forgotten to mention that a major goal of this software is to aid in fixing the underlying wireless issues, and this seemed important. Anyway, the script saves a portion of the last 7 link quality statistics prior to failure, adds the first statistics after failure, and saves it for later upload when the link is restored, usually within a minute. For those interested, a new -vt option uploads statistics every 20 seconds, for a nearly complete record.

    As before, the version 0.5.0 software consists of 2 scripts and 3 text documents. The "manual.txt" document has installation and usage instructions. Here is the "wlanpoke.0.5.0.zip" file.

    As usual, your kind comments and suggestion are welcome.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •