**** BEGIN LOGGING AT Mon Jul 08 02:59:58 2019 Jul 08 16:29:48 is unstable wifi a known issue on beagle bone green wireless (or wl18xx-based boards in general) ? I have very unstable wifi Jul 08 16:31:29 sometimes it works very well for a few minutes and then it seems to get worse and worse Jul 08 16:34:12 mickael9: a couple things would cause that, first lets see what you are running: please run: sudo /opt/scripts/tools/version.sh and copy that data to https://paste.debian.net/ so we can read it.. Jul 08 16:35:29 Had the same wifi issue while configuring it from /e/n/interfaces. Purging systemd fixed it for me Jul 08 16:35:29 currently, I'm running your buster image which I compiled, but I had the same problems with the precompiled one (bone-debian-9.9-console-armhf-2019-06-15-2gb.img.xz) Jul 08 16:36:18 http://ix.io/1O2Z Jul 08 16:39:37 sorry, yeap that has pretty much all the known work arounds (power managment disable, firmware, kernel, crda..) only thing left is your power supply (really wish they didn't use the usb jack..) you could try the v4.19.x-ti kernel. Jul 08 16:40:39 i use these adapters to bypass the usb power: https://www.adafruit.com/product/2727 Jul 08 16:40:51 you think it's related to power? Jul 08 16:43:42 personally, i haven't had much luck on the "green's" with there usb power port.. You might have a usb charger/port that works, i gave up and started using those usb/barrel adapters.. Jul 08 16:44:39 I have a black wireless too, I'm gonna run the same tests with that one Jul 08 16:52:31 nah wifi sucks too, and I'm too confident in plugging an adapter since I have a cheap ftdi cable for the console Jul 08 16:53:38 last time I managed to make my screen flicker by plugging an ftdi to the beaglebone (it was powered with an AC adapter) Jul 08 17:07:12 I think we're onto something, when plugged directly into my computer's USB, it's very bad very quickly, but works much better using my phone charger Jul 08 17:07:48 funnily enough, it seems to work well when I use my computer's USB port through a cheap unpowered USB hub Jul 08 17:33:30 Humpelstilzchen: ehhh what? Jul 08 17:36:37 I'm now on the black wireless with a good adapter, still experiencing problems, and I can reliably make the connection drop Jul 08 17:36:46 ...by standing in a particular position Jul 08 17:37:04 so much for mimo Jul 08 17:37:12 Humpelstilzchen: sounds like you had two network managers (ifupdown and connman) fighting over control and "fixed" it by breaking a ton of services instead of just making sure only one is used. (I'd personally use neither, I use systemd-networkd) Jul 08 17:37:45 mickael9: mimo is problematic due to the beaglebone's small size.. the antennae kind of need to be further apart than they can be Jul 08 17:38:12 mickael9: configuring them at 90 degree angle (i.e. sticking out in a V-shape) is probably the best you can do Jul 08 17:38:21 I'll try with ht_mode=wide Jul 08 17:38:32 that will make things worse probably Jul 08 17:53:48 one thing I noticed is that if when radio is interrupted for a few seconds, it takes like 5sec to recover Jul 08 17:54:04 by interrupted I mean putting a baking sheet near the antennas :D Jul 08 17:54:13 that sounds really weird Jul 08 17:54:38 wait, what do you mean by "baking sheet" ? Jul 08 17:56:27 a big metal sheet to disturb the signal Jul 08 17:56:32 oh Jul 08 17:56:44 oven tray? Jul 08 17:56:51 yes Jul 08 17:57:13 the recovery time doesn't sound strange to me if the connection drops, but the fact the connection drops after only a few seconds does sound very strange to me Jul 08 17:58:36 any idea how I could get some more logging? Jul 08 17:58:45 wpa_supplicant perhaps? Jul 08 17:59:12 btw I tried iwd too, same problem Jul 08 17:59:41 you could enable debug logging in that yes (via wpa_cli). the wifi chipset itself also has logging features but I don't really remember any details, it's been ages since I've done any digging into that Jul 08 18:13:57 mickael9: hmm, I just ran a test that pinged a bbbw here every 0.05 s and then tried shielding it using aluminium foil... I guess I didn't do a good enough job, since I didn't get even the slightest irregularity in the ping log Jul 08 18:14:00 zmatt: could be, I never configured conman and if I would have seen its process in ps ax I would have purged its package Jul 08 18:14:21 I probably did remove it, can't remember Jul 08 18:14:55 mickael9: it's very close to the base station though, so that's probably why Jul 08 18:15:16 yeah I'm not sure it's effective, the position needs to be just right, I can seem to be able to make it drop with juste my hand over the antenna Jul 08 18:15:29 my wifi router is 2 meters behind me Jul 08 18:15:39 odd Jul 08 18:15:50 that really doesn't sound normal Jul 08 18:15:55 it might work better with some channels too Jul 08 18:16:14 one day it was really bad, I restarted the wifi on by router and it worked better Jul 08 18:16:21 at 2m distance it really shouldn't matter Jul 08 18:16:54 I have freq 2447 Jul 08 18:17:12 -33dBm signal Jul 08 18:18:36 I can get it to drop down to -50 with my hand over it Jul 08 18:20:05 I do pingfloods to my local computer to check the packet loss in realtime Jul 08 18:20:10 ping -f 192.168.0.1 Jul 08 18:21:37 how are your antennae oriented? Jul 08 18:23:30 very badly, probably they are sticked to the GPIO headers Jul 08 18:23:41 ehh what Jul 08 18:26:44 they should be rotated outwards like https://photos.app.goo.gl/tgXV8iQo3SQCrmdG8 Jul 08 18:27:42 (the close proximity to the usb cable is unfortunate but can't be helped) Jul 08 18:29:34 if they're still in their shipping-configuration (rotated inward) then yeah I can imagine you'd have very crappy wifi Jul 08 18:29:55 https://photos.google.com/share/AF1QipOmRb8MoAjmzeTMaO5Y5dEexEXBvRtMUmJxQpBgh3ez_geq_mcQNFo7awY9q_LnIw/photo/AF1QipMHv_AcolEDsYjnX7phi7fa3Hitc5kDczcOPu_6?key=czBGRGZUUGdkMHIwajlMckhvcWthX3l4OVN0VzVB Jul 08 18:30:48 uhh, why are they like that? Jul 08 18:32:05 they needed to fit into a custom case and that layout was chosen without too much thinking :/ Jul 08 18:32:48 well this way you have no access to (most of) the expansion headers, and if wifi works at all it'll be by complete accident Jul 08 18:33:17 the antennae need to be away from the board, i.e. https://beagleboard.org/static/images/BBGW_vertical.png Jul 08 18:33:49 (I'd also suggest trying to keep them further apart from each other than shown in this image) Jul 08 18:34:52 damn the glue is strong Jul 08 18:37:51 (btw, when designing a cape or doing anything with the expansion headers in general, beware that the BBGW (unlike the BBBW) uses a whole bunch of expansion header pins for the wifi chipset, which therefore can't be used for other purposes, and seeed neglects to properly document this) Jul 08 18:42:06 (though I guess you're not doing anything with the expansion headers :P ) Jul 08 18:42:08 with the antennas correctly placed, the dropouts are rare but still happen, the throughput is way better though Jul 08 18:42:38 actually, it's gone into shit mode again, with very low throughput Jul 08 18:42:51 < 100 kB/s Jul 08 18:43:14 (it can go up to >2 MB/s) Jul 08 18:43:58 yeah, no need for the expansion headers :p Jul 08 18:44:34 I don't really have time to experiment more with the bbbw here... I'm pretty sure that when I did testing with it, it seemed to work okay. the only problem I've experienced is that the wl18xx firmware occasionally crashes, but the kernel driver quickly detects that and recovers without the wifi connection dropping Jul 08 18:46:09 yeah I've had that too, but it's pretty rare Jul 08 18:48:29 anyway, even with the antennas angled in a V shape, I can still make it drop out just by putting myself between the router and the bbgw Jul 08 18:49:55 I'm not sure it's a solvable problem, thanks a lot for your help Jul 08 19:01:08 I've tried removing the antennas, it seems to be way more stable with the on-chip antenna.. Jul 08 19:01:53 plugging an antenna to ANT2 (the one that isn't connected to the chip antenna) makes it unreliable Jul 08 19:03:48 wait, the bbgw has an on-board antenna? how do you select between that and external antenna? Jul 08 19:04:18 * zmatt stares in confusion at the schematic Jul 08 19:05:02 what... but... how... what? Jul 08 19:06:32 they basically just wired the U.FL connector in parallel with the on-board one o.O Jul 08 19:06:40 *on-board antenna Jul 08 19:07:27 mickael9: yet you're saying connecting ANT2 makes things unreliable, not ANT1 ? I have rarely been more puzzled Jul 08 19:08:49 yeah somehow Jul 08 19:09:03 plugging any antenna seems to make it more prone to dropouts Jul 08 19:10:04 perhaps it's just because I can't block the chip antenna in the same way though Jul 08 19:10:18 what's strange is adding an auxiliary antenna making things worse Jul 08 19:10:50 adding ANT2 should only be able to make things better, definitely not worse Jul 08 19:12:07 well I added the small wire antenna from the black, it makes it worse too Jul 08 19:12:36 maybe your beaglebone is haunted, try an exorcism Jul 08 19:14:04 lol Jul 08 19:14:28 it seems fine with the black's antenna on ANT1 too Jul 08 19:14:44 perhaps it's ANT2 that's cursed Jul 08 19:15:23 I'm gonna try ht_mode=wide and see if plugging ANT2 still makes a difference Jul 08 19:15:42 ht_mode=wide this doesn't use ANT2 right? Jul 08 19:18:07 in case it's of any use, these are the firmware and configs (in /lib/firmware/ti-connectivity) I used when I last did stuff with the wilink8 => https://liktaanjeneus.nl/data/public/wilink8/ti-connectivity.tar.xz ... the firmware is probably out of date though. I never used overrides via kernel module parameters myself, just the config files (which are basically stock/example iirc) Jul 08 19:19:41 yeah presumably that means the siso40 mode? which in practice is rarely if ever effective on 2.4 GHz Jul 08 19:20:03 mimo should give the best result Jul 08 19:20:36 wait that link is wrong Jul 08 19:20:41 do phones have mimo antennas? Jul 08 19:20:45 https://liktaanjeneus.nl/wilink8/ti-connectivity.tar.xz Jul 08 19:21:06 wilink8 was originally for phones afaik Jul 08 19:22:25 seems that it works much better with ht_mode=wide, and plugging ANT2 doesn't change that (finally something that makes sense lol) Jul 08 19:22:40 that's really weird Jul 08 19:23:44 damn it's SO stable Jul 08 19:24:22 like 0 packet loss Jul 08 19:24:46 but the throughput is shit Jul 08 19:25:09 which firmware version are you using ( dmesg | grep 'wlcore: firmware booted' ) Jul 08 19:25:29 the latest, I checked Jul 08 19:25:32 ok Jul 08 19:25:36 it hasn't been updated for like 1 year anyway Jul 08 19:25:56 https://git.ti.com/wilink8-wlan/wl18xx_fw/ Jul 08 19:26:02 I mean, who knows you could have been using some old image... happens often enough :P Jul 08 19:26:27 that was the first question I was asked :p Jul 08 19:26:35 hehe Jul 08 19:26:48 it's a debian buster built from rcn's script Jul 08 19:27:30 http://ix.io/1O2Z Jul 08 19:29:42 brb Jul 08 19:30:39 do you have any idea why there's a specific ht_mode=default in /etc/modprobe.d/wl18xx.conf ? it's already default Jul 08 19:31:00 there must have been a good reason for this file to be added Jul 08 19:31:43 someone at ti recommended it.. Jul 08 19:31:57 does it fix things if you remove that? Jul 08 19:32:27 no, it's already default in the kernel module itself Jul 08 19:33:23 better question... was it always default.. thinknig about v4.1.x/v4.4.x era.. Jul 08 19:33:48 otherwise for buster, probally safe to nuke the file Jul 08 19:34:21 oh wait Jul 08 19:34:32 it differs on some kernels Jul 08 19:37:40 I might be hallucinating but I'm pretty sure I saw it defaulted to HT_MODE_DEFAULT in the kernel somewhere Jul 08 19:39:11 https://github.com/RobertCNelson/ti-linux-kernel/commit/50e4c905a0c782b8a5717ed0d907c53d82c16ce2 that commit is 6 years old Jul 08 19:39:24 it's indeed defaulted to WIDE so I guess the file needs to stay Jul 08 19:40:39 perhaps ti recommended it because the beaglebone have two antennas and the kernel module doesn't know that and uses only one by default Jul 08 19:41:17 well the firmware is setup for dual antennas (2.4ghz) it's one of the bits you define... Jul 08 19:42:09 wide is default on mainline: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ti/wl18xx/main.c?h=v5.2#n508 Jul 08 19:43:26 what do you mean when you say the firmware is setup for dual antennas? where is that defined? Jul 08 19:44:27 3 modes, HT_MODE_DEFAULT, HT_MODE_WIDE (the real default), and HT_MODE_SISO20 Jul 08 19:45:10 https://github.com/beagleboard/beaglebone-black-wireless/blob/master/firmware/WL1835MOD_INI_C2PC.ini#L20 Jul 08 19:55:30 how does this kernel parameter relate to the wl18xx config file? (which also contains that mode) Jul 08 19:55:47 ah, which you pointed to Jul 08 19:57:11 that support was probally never written... Jul 08 19:57:18 looks like wl18xx_default_priv_conf is only used if the config file fails to load Jul 08 19:57:27 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ti/wl18xx/main.c?h=v5.2#n1444 Jul 08 19:58:20 but the ht_mode kernel parameter, if specified, overrides the config file => https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ti/wl18xx/main.c?h=v5.2#n1985 Jul 08 19:59:06 so basically the kernel parameter should only be used if the config file is wrong Jul 08 19:59:58 isn't it just that the config file doesn't directly specify the mode to use, just the antennas that are present, and the driver chooses the mode to use? Jul 08 20:01:03 no, the config file includes the ht mode parameter Jul 08 20:02:37 https://pastebin.com/XvKAUQh5 Jul 08 20:03:53 looks like the beaglebone's config file (here named wl1835-bb.conf) at the time I dealt with this stuff (a while back) was set to siso40 instead of mimo, and the kernel parameter was probably introduced to override that Jul 08 20:04:08 oh, I thought the config file was the ini file Jul 08 20:04:30 nah iirc the ini is just used by the scripts that generate the config file Jul 08 20:05:03 these .conf files are the text representations, the actual config files have a binary format Jul 08 20:05:24 there's a new config in the ti repository you mentioned, I might give that a try Jul 08 20:08:19 ? I didn't mention any ti repository Jul 08 20:10:56 http://git.ti.com/cgit/cgit.cgi/wilink8-wlan/18xx-ti-utils.git/log/wlconf/official_inis/WL1835MOD_INI_C2PC.ini Jul 08 20:11:36 yours is on R8.6SP1 Jul 08 20:12:56 rcn linked to that, not me Jul 08 20:13:37 oh, sorry Jul 08 20:15:21 you can find my config in the tarball I linked to earlier... looks like those are from early 2018 Jul 08 20:21:10 yeah the binary in /lib/firmware/ti-connectivity/wl18xx-conf.bin matches the one in the beaglebone-black-wireless repo Jul 08 20:21:57 it's on R8.6SP1 so out of date it would seem Jul 08 20:22:16 probably won't change anything though, let's test that Jul 08 20:28:35 nah still sucks Jul 09 02:56:40 I am, w/ the 4.14.x kernel, trying to find out which gpiochip0, 1, 2, 3, has the GPIO_12 in it. Do you know what I might be doing that is creating me to not find it in the 4.14.x kernel? Jul 09 02:56:40 ... Jul 09 02:57:04 I ask b/c the lesson I found is on kernel 4.19.x and not 4.14.x. Jul 09 02:57:35 I am basically trying to find the major and minor of the GPIO_12 pin. Jul 09 02:57:43 do you have zmatt 's pin script/spreadsheet ? Jul 09 02:57:49 Oh. Jul 09 02:57:56 Yea. I can get it. Jul 09 02:58:02 I remember the link. Jul 09 02:58:06 mvduin. Jul 09 02:58:16 I do not have it right now, though. Jul 09 02:58:21 I will go and look. Jul 09 02:59:07 veremitz: After 4.19.x and w/ that kernel, it seems easier to use the character device ideas. Jul 09 02:59:51 I think maybe the char. dev. ideas were not ported to the 4.14.x kernel on the BBB.io/latest-images. **** ENDING LOGGING AT Tue Jul 09 02:59:57 2019