**** BEGIN LOGGING AT Fri Mar 12 03:00:02 2021 Mar 12 03:07:57 Dang it. Mar 12 03:09:13 I did all this work. "Do I know why it is not working?" Yes. Can I fix it? Yes. Will I fix it, no. I will not, should not, could not. Mar 12 03:11:44 But why, why will I not fix it? B/c...b/c there are other projects that demand attention. Man, one vaccination and I am up donkey's creek w/out a saddle. Mar 12 03:11:52 Oh well. Mar 12 03:11:56 Another time I guess. Mar 12 03:12:17 BBB! Mar 12 03:12:55 Speaking of things...does anyone have a clue as to how to get emcapplication/machinekit-hal to work on the BBB currently? Mar 12 03:13:50 There is no way that actually works currently (I believe). Mixing py2 w/ py3 is not collective in source. Mar 12 03:14:09 I built it so many times and w/ no functionality so far. Mar 12 03:14:21 LinuxCNC it is. I try. Mar 12 03:17:21 So, the reason I kept and keep bringin' it up is this idea. "I got this hardware set up for workings on the BBB w/ a nice motor and the project has taken time out of my regular 'schedule' of other projects... Mar 12 03:18:11 I figured since the co. produced a set of instructions for the BBB w/ machinekit in mind, well, that was the route to take. Mar 12 03:18:16 Boink! reality! Mar 12 03:19:21 Use LinuxCNC. ONLY! I tried to get assistance. I probably made everyone upset since I have been just reconfirming that nothing works. I feel terrible. Anyway GenTooMan, somehow this is your fault. Mar 12 03:19:21 Ha. Mar 12 03:20:08 You tested me one day about my tiny half duplex UART servos and then I went down this path of, "I will show him!" Mar 12 03:20:09 ha. Mar 12 03:25:26 I still have not showed you! So, please be patient and the project will come together soon...yes sir! Mar 12 04:17:13 what bios does beagle use Mar 12 04:44:58 he didn't hang around for an answer... Mar 12 04:51:16 Please help with SPI sample code example of Beaglebone Black Wireless board (SPI_Dev1.0/2.0) Mar 12 05:07:52 Use SPIDEV0.0! Mar 12 05:07:57 GenTooMan! Mar 12 05:27:51 I already setup spi dev0.0 but the data is not transmitting, I want to send the data through BBB Wireless(Master) to ST Nucleo-F7xx (Slave) microcontroller board via SPI comm Mar 12 05:36:10 BB-SPIDEV-00A0.dtbs Mar 12 05:36:12 sorry. Mar 12 05:36:43 BB-SPIDEV-00A0.dtbo is what to put in your /boot/uEnv.txt file from the repos. online from beagleboard.org. Mar 12 05:37:11 Also, the pins may be backwards. I cannot be completely, 100% sure. Mar 12 05:37:29 So, COPI and CIPO may need to be switched. Mar 12 05:38:48 But CS and CLK are what they say they are as far as i can tell. Mar 12 05:39:22 So, CS0 and CLK0.0 are what they are on the BBB, BBG, and other boards. Mar 12 05:40:50 But...at least on my BBG, I had to superimpose the pins w/ an ole switch-a-roo. Mar 12 05:41:47 What line I have to add in /boot/uEnv.txt file Mar 12 05:42:32 BB-SPIDEV-00A0.dtbo under where is shows the uboot-overlays. Mar 12 05:42:57 Also...I would update the kernel to the current release candidate. Mar 12 05:43:00 uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtbo Mar 12 05:43:05 Fine. Mar 12 05:43:08 I have added this line Mar 12 05:43:11 Oh. Mar 12 05:43:13 ! Mar 12 05:43:15 but still is not Mar 12 05:43:16 Good move. Mar 12 05:43:18 Oh. Mar 12 05:43:40 Put MOSI where MISO is and vice versa. Mar 12 05:43:46 Try that but... Mar 12 05:43:58 If things go awkward, I am not at fault. Mar 12 05:44:02 I am sure you can test first. Mar 12 05:44:22 So, short the pins MOSI to MISO and see if you are getting any feedback. Mar 12 05:44:25 So, I have to connect MOSI & MISO short Mar 12 05:44:51 I tried that also Mar 12 05:44:56 Right. Turn off the board, leave the rest of the pins unaccounted for... Mar 12 05:44:57 Oh. Mar 12 05:45:01 Okay. Mar 12 05:45:07 What happened? Mar 12 05:45:09 where I can check SPIDev source code Mar 12 05:45:26 in bb.org-overlays or in /lib/firmware/ Mar 12 05:46:27 so, in /lib/firmware/, there should be a dts and other type of file but if you want to change things... Mar 12 05:46:57 i say clone from githuh.com the bb.org-overlays from github.com/bb.org-overlays. Mar 12 05:47:23 That way, you can exchange formatting of the source. Mar 12 05:47:44 * anupammishra[m] uploaded an image: (123KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/zQgPCsGsStvedPCNJDWavRRI/SharedScreenshot.jpg > Mar 12 05:47:49 I am getting this value Mar 12 05:48:06 What is matrix.org/_matrix.../.../.../? Mar 12 05:48:13 Is that just a photo? Mar 12 05:48:31 Oh. Mar 12 05:48:41 Are you using Dr. Molloy's book on this effort? Mar 12 05:48:48 * anupammishra[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/SiNaZyIxtvmHTjFRCUxDrxqw/message.txt > Mar 12 05:48:57 I am transmitting this data Mar 12 05:49:14 Try to change his source in his file and then build it again. Mar 12 05:49:16 but getting all zero Mar 12 05:49:31 Right. Mar 12 05:49:35 I had that issue. Mar 12 05:49:43 Ohh ok Mar 12 05:49:53 So what can I follow Mar 12 05:50:08 Let me make sure of something real quickly and then be right back. Is that okay? Mar 12 05:50:21 Yes sure thank you Mar 12 05:50:54 Look at this: https://github.com/derekmolloy/exploringBB/blob/version2/chp08/spi/spidev_test/spidev_test.c Mar 12 05:51:13 Line 32 shows the issue of the source not being SPIDEV0.0. Mar 12 05:51:25 He wrote that source for spidev1.0. Mar 12 05:52:11 same results all zeros Mar 12 05:52:31 did you build it again? use the build file in his repo. Mar 12 05:53:54 so, change line 32 to be "/dev/spidev0.0", type build, and then type ./spidev_test. Mar 12 05:54:02 yes, but no result Mar 12 05:54:17 Still 00 00 00 00...n? Mar 12 05:55:06 ok Mar 12 05:55:23 after this command ./spidev_test Mar 12 05:55:25 can't open device: No such file or directory Mar 12 05:55:29 it is showing Mar 12 05:55:46 I would make sure you shutdown the board, short SPIDEV0.0 on MISO/MOSI or if you call them CIPO/COPI, short those pins on the BBBW, and then fix up the issue like I described. Mar 12 05:55:48 ... Mar 12 05:55:49 Oh. Mar 12 05:56:11 1. fix line 32 Mar 12 05:56:11 Ok, I ll follow the same Mar 12 05:56:16 2. build Mar 12 05:56:23 what about clock pin Mar 12 05:56:33 3. ./spidev_test Mar 12 05:56:38 Do not worry about it. Mar 12 05:56:42 ok Mar 12 05:57:03 All you need is to short MISO/MOSI. Mar 12 05:57:09 thank you for help Mar 12 05:57:51 And, if you just typed in BB-SPIDEV0-00A0.dtbo into /boot/uEnv.txt, reboot first. Mar 12 05:58:11 did it work? Mar 12 05:58:58 I would say it is late but the handyman is going to wake me up early by bangin' on the door. I can help still. Mar 12 05:59:01 brb Mar 12 06:03:12 yeah I have done that after adding reboot the board, ohh ok i will try to fix the problem, thank you Mar 12 06:03:35 Oh. Okay. so... Mar 12 06:04:49 add the .dtbo file, short the pins, reboot, change line 32, build, run the source ./spidev_test, and then that should do it. Mar 12 06:06:05 I will try on my side w/ the BBBW. Did you update your kernel yet? Mar 12 06:07:04 Kernel update not done, can you please which pin no on P9 connector Mar 12 06:07:38 after changing line 32 i.e. 0.0 code is not compiling Mar 12 06:07:57 I have shorted 18 & 21 pins on P9 connector Mar 12 06:08:29 Okay. Let me check mine and get back to you. Mar 12 06:08:35 one moment. Mar 12 06:08:37 ok Mar 12 06:09:42 Can I send this data ( 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, Mar 12 06:09:42 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, Mar 12 06:09:42 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF) to any micro board connected to BBB W using SPI comm Mar 12 06:10:41 I think you need to send in your own microcontroller source to the board when relaying communication, i.e. if that makes sense. Mar 12 06:10:48 BBB W ---->>>> SPI ------>>> STMicroelectronics Nucleo-F767 board communication Mar 12 06:11:04 Sure. You can do that but how is the question... Mar 12 06:11:16 I want BBB as a master and micro as a slave Mar 12 06:11:29 You need a good set of source to run the MCU from the BBB. Mar 12 06:11:45 ok once SPI will work on BBB then I will try to do Mar 12 06:11:52 You can use SPI, i2c, UART, and so on. Mar 12 06:12:02 yes Mar 12 06:12:15 which PIN no ?? Mar 12 06:12:22 Oh. Mar 12 06:12:24 Let me check. Mar 12 06:13:19 P9.18/21 Mar 12 06:13:41 yes same pin no I have connected but Mar 12 06:13:45 no result Mar 12 06:14:29 https://beagleboard.org/Support/bone101 has a list of pins for SPI. Mar 12 06:14:44 Scroll down to make sure you are using the correct pins. Mar 12 06:14:55 I am cloning the repo now. Mar 12 06:15:37 I have counted incorrectly before when many wires are attached. Mar 12 06:15:38 ok Mar 12 06:15:50 I ll check Mar 12 06:16:00 It might be a safe bet to count over and over until you are 100% sure. Mar 12 06:16:05 Just an idea. Mar 12 06:17:34 It's done Mar 12 06:17:54 4.19.94-ti-r59 is what needs to be on your 4.19.x kernel, sort of. Mar 12 06:17:57 What is done? Mar 12 06:18:02 It's working I am getting data , sorry just pin connection and working with 1.0 Mar 12 06:18:09 Oh. Mar 12 06:18:10 Okay. Mar 12 06:18:11 Nice! Mar 12 06:18:17 Good luck! Mar 12 06:18:24 Thanks!! Mar 12 06:18:31 Yep. Mar 12 08:19:30 Hello, Mar 12 08:19:30 I am trying to communicate BBB W (as master) board to a microcontroller (SPI) board via SPI communication. I am trying to get the sensors data of slave board in BBB W. I have established communication but enable to send & receive data.... Does anyhave the source code of SPI (BBB W)?? Mar 12 08:22:39 I don't know what you mean by "the source code of SPI", but I have a short tutorial on using SPI: https://pastebin.com/nS6FELGH Mar 12 08:23:12 also, didn't you earlier say you had it working? Mar 12 08:23:16 07:18 <+anupammishra[m]> It's working I am getting data Mar 12 08:24:14 When I short MOSI & MISO and what data I sending I am able to receive in rx buffer Mar 12 08:24:44 okay, so the spi port works Mar 12 08:27:19 * anupammishra[m] uploaded an image: (131KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/uxTfvCuzRmxOMlqYuqKVYCBk/sss.jpg > Mar 12 08:27:26 yes, this is the result Mar 12 08:28:02 okay, so SPI is working fine Mar 12 08:28:37 yeah, but this data want to send to micro & receive any from micro Mar 12 08:28:56 that's a question about your microcontroller, not about the BBB Mar 12 08:28:56 *any data Mar 12 08:29:33 I am sending data from micro via spi but not to get in rx buffer of BBB W Mar 12 08:30:33 spi is completely controlled by the master, the slave has no influence over *when* data is being transferred Mar 12 08:31:27 so slave can not send data to BBB Mar 12 08:31:29 which means spi slaves are tricky to implement and have strict real-time constraints Mar 12 08:31:40 ok Mar 12 08:31:51 real-time constraints ??? Mar 12 08:32:03 a slave transfers data to the BBB at the same time the BBB transfers data to the slave Mar 12 08:32:06 that's how SPI works Mar 12 08:32:13 any RTOS I have to implement, like FreeRTOS or any Mar 12 08:32:38 the slave cannot choose when data is transferred, the master chooses when data is transferred Mar 12 08:32:48 you don't need to use an RTOS Mar 12 08:33:14 if you want a serial communication protocol that is easier to work with, use an UART instead of SPI Mar 12 08:34:06 If master as BBB is waiting for data from slave then how it ll work Mar 12 08:34:14 the master never waits for data Mar 12 08:34:25 the master performs transfers when you request them from userspace Mar 12 08:34:39 data is then transferred in both directions (master->slave and slave->master) at the saem time Mar 12 08:34:42 wait means master in interrupt mode Mar 12 08:34:50 when data comes it ll receive Mar 12 08:34:58 it is the slave's responsibility to have data ready to send when the master asks for it Mar 12 08:35:17 the master will never wait for the slave to be ready Mar 12 08:35:55 okk Mar 12 08:35:57 (the master does not _know_ whether the slave is ready, or whether it has data to send) Mar 12 08:36:20 that is why it is difficult to implement an spi slave Mar 12 08:41:26 ok I ll check Mar 12 10:02:13 any one got experience running multiple soc's on one mcasp interface ? Mar 12 10:02:36 what do you mean? Mar 12 10:04:28 we have connected two socs to a single mcasp interface (in this case mcasp 0) and i am struggeling to configure which AXR (is the audio serial stream output/input) is used for which soc Mar 12 10:05:04 what do you mean by "two socs" ? Mar 12 10:05:30 two audio codecs Mar 12 10:05:43 two devices Mar 12 10:05:50 okay, a soc is a system-on-a-chip like the am335x, which is why your question was so confusing Mar 12 10:06:20 oh sorry sometimes the kernel docs refer to them as soc's Mar 12 10:06:31 where? Mar 12 10:07:11 (and yes, what you're describing sounds like "fun" to configure... ASoC (ALSA-for-SoCs) is hell) Mar 12 10:08:25 oh i think i read it wrong the docs do refer to soc's but they meen the chip (am335x) in this case :) Mar 12 10:08:40 like, from a hardware point of view it shouldn't be a problem, but alsa seems to make simple things hard and hard things impossible Mar 12 10:09:36 I ended up patching the mcasp driver and writing a custom codec driver just to get *simple* things working :P Mar 12 10:11:19 and I'm still tempted to dump alsa entirely and use PRU to transfer audio data between mcasp and userspace via ringbuffers in shared memory, cutting the kernel out of it entirely Mar 12 10:20:31 I'm pretty sure that even if you do get it configured right, your multiple audio codecs will not show up as separate audio devices, but instead as a single multi-channel audio device Mar 12 10:21:16 but it's been a while since I've dug through alsa, and I've repressed most of the memories Mar 12 10:22:14 Hi All, It's Onural from Turkey, Mar 12 10:22:21 zmatt: they already show up as a single multi-channel audio device (which is highly confusing) Mar 12 10:22:35 We need Beaglebone with KINGSTON 2400450-0001.A0G-A EMMC04G-S100 Mar 12 10:22:41 but i need to configure where the in/out streams go Mar 12 10:23:08 Onural: this is a community chat, not a sales channel Mar 12 10:23:25 Sorry :) Mar 12 10:23:40 Onural: ask your distributor (though I don't think you generally get a choice in the eMMC chip used) Mar 12 10:24:01 But anybody knows any supplier - because we can't find in Turkey Mar 12 10:25:44 for the beaglebone black? Mar 12 10:26:52 digikey has them in stock, mouser has them in stock, okdo has them in stock Mar 12 10:28:15 element14 doesn't seem to have them in stock currently (though they do have the functionally equivalent beaglebone black industrial) Mar 12 10:31:52 like I said, the eMMC used is not specified, the EMMC04G-S100 used to be the one typically used on the BBB, though currently it typically seems to be the newer Kingston EMMC04G-M627 Mar 12 10:33:38 this shouldn't matter unless you're using a _really_ ancient kernel, and even then all you need to do is use the latest package for that ancient kernel series (since rcn patched the older kernels to support eMMC 5 devices) Mar 12 10:35:29 Duality: yeah, our problem was that we wanted to use the transmit and receive sections of the McASP independently Mar 12 10:42:55 oh element14/farnell/newark *does* have the BBB in stock, it's just impossible to find as it's listed as "102110420" Mar 12 10:46:49 jkridner[m]: the element14 "buy from" link for the BBB points to an element14 page that says the BBB is no longer available, while the BBB is in fact in their store but impossible to find (neither "beaglebone black" nor "bbone-black" will find it, it's listed as "102110420"). I understand this is due to switching manufacturer to seeed, but it does need to be fixed ;) Mar 12 13:40:14 Hi, I have cellular modem integrated into BBBw. Is there a way to configure WIFI and Cellular with wifi access precedence as iPhone configuration? Mar 12 15:02:22 after I did: sudo apt-get update && sudo apt-get upgrade, I got : W: Couldn't identify type of root file system for fsck hook. It seems related to my etc/fstab file? Mar 12 15:14:34 tiger: Did you update your kernel yet? Mar 12 15:14:51 r59, I think, is the current release... Mar 12 15:16:29 My kernel: 4.19.50-ti-r20 Mar 12 15:17:07 I added usb automount in the /etc/fstab file. I am not sure that line causes the warning Mar 12 15:23:38 set_: why would he need to update it? Mar 12 15:24:10 tiger: pastebin your fstab Mar 12 15:24:51 tiger: because that sounds like you messed up the fstab line for your root filesystem Mar 12 15:25:52 https://pastebin.com/AGybq5Li Mar 12 15:26:36 okay that's odd Mar 12 15:27:11 I added the last line for automount usb for ext4 partition Mar 12 15:28:12 BTW: can I remove debugfs in the fstab file? Mar 12 15:28:48 why would you want to? Mar 12 15:28:59 it's generally a good idea to have debugfs mounted Mar 12 15:29:36 though I think it gets automatically mounted anyway Mar 12 15:29:54 Well, If it is not used. Try to make it simpler for product release. If it is needed. Ok, leave it there. Mar 12 15:31:25 the only impact removing that line will have is that it will be mounted with the default permissions (i.e. only root access allowed) instead of the ones configured in fstab Mar 12 15:32:14 I have no idea why you're getting that spurious warning from initramfs-tools Mar 12 15:32:49 I thought you may have hit a snag of old source, @zmatt. Mar 12 15:32:59 set_: ? Mar 12 15:33:40 Well, I figured the fellow, tiger, was using an older set of overlays. Mar 12 15:33:44 That was my first idea. Mar 12 15:34:01 overlays? what are you even talking about? what does that have to do with anything? Mar 12 15:34:09 And...w/ the updated kernel, an updated set of overlays. Mar 12 15:34:28 I do not know. Just commenting out specific ideas first off. Mar 12 15:34:55 I am installing the Native_SDK now w/ the PVRserver. Mar 12 15:35:01 Graphics! Mar 12 15:35:39 My board is flashed with the image : Bone-debian-10.0-iot-armhf-2019-07-07-4gb.img.xz Mar 12 15:35:53 Oh. Okay. Mar 12 15:36:23 that's pretty old Mar 12 15:36:38 I would update that sucka', sir. At least to 2020-xx-04 Mar 12 15:37:40 depends on the situation of course, if you've already invested a lot of time into a system and don't have any problems with it there's no reason to reflash Mar 12 15:37:57 manually updating can get you most of the way there Mar 12 15:39:12 although updating the bloated iot system can be tricky since installing updates temporarily requires more disk space, and you really don't want to run out of space in the middle of an update Mar 12 15:40:17 I know. But I found there is problem with the latest release. It has been for some time, I think it is related to GPIO exports. I have contacted with Mr. Robert Nelson with this. So I have to fix it to that version. Mar 12 15:40:31 what problem? Mar 12 15:41:00 I've not seen or heard of any gpio-related problems on the latest images Mar 12 15:42:59 It has been for a while. My best recollection is debian@beaglebone:/sys/class/gpio$ folder doesn't have a lot of gpio pins exported. Let me check my support record with TechForum. I give back to you Mar 12 15:45:47 tiger: sometimes exporting gpio pins is needed to use them. For instance, w/ config-pin, a .dtbo, or in source, and on the command line too. Mar 12 15:46:12 I know you know but... Mar 12 15:46:19 current image in stock configuration has all gpios exported by default, except those in use for other functions Mar 12 15:46:23 set_: ehm, no Mar 12 15:46:26 I figured I would jus say it. Mar 12 15:46:26 set_: stop saying nonsense Mar 12 15:46:30 Fine. Mar 12 15:46:55 when cape-universal is enabled you never need to manually export gpios Mar 12 15:47:12 and config-pin does not, and has never, exported gpios Mar 12 15:47:22 Well, that depends on if he is utilizing specific pins on a .dtbo or not. Mar 12 15:47:41 Well, not export w/ config-pin but you can alter their state still right? Mar 12 15:47:57 Ok, here is the link: https://forum.digikey.com/t/pin-mux-p9-26-not/8750 Mar 12 15:48:04 set_: you're just confusing things Mar 12 15:48:13 Fine. I will chill out. Mar 12 15:49:24 tiger: what am I looking at? this is a post of someone being confused and getting help, there's no problem with the image described here Mar 12 15:50:52 to be short: the command: config-pinsĀ  for configuring P9_26 works on 2020-07-07 version. May have issue with other version Mar 12 15:51:29 config-pin works fine for those pins on the latest image Mar 12 15:52:30 pins that are used by a cape or custom overlay will have their function configured by the overlay, hence those are not reconfigurable by config-pin Mar 12 15:52:52 that is normal behaviour, not a bug Mar 12 15:53:22 (it is not clear from the post what cape or overlay they're talking about) Mar 12 15:53:59 they/you .. is this your post? Mar 12 15:55:01 rcn explained it quite clearly I think, so it's not really clear what you're talking about Mar 12 15:55:18 if you want to use config-pin, don't load an overlay for CAN Mar 12 15:55:22 no overlay is required for it Mar 12 15:55:38 I got a joke. I CAN run! Mar 12 15:57:35 I couldn't remember what was exactly. But now we have flashed 2019-07-07 for our production release. And many things have been tested for that version. Any upgrade to a new version will involve a lot of installing (offline), setup, configuration, and test. Mar 12 15:58:24 sure, that's fine, but just be aware there's no problem with current image, you were just confused Mar 12 15:59:00 (or at least that thread does not describe or suggest any problem with current image) Mar 12 15:59:57 When I have time, I will load the latest released image to do a test, if any issues emerge. Mar 12 16:02:06 I have some WIFI Access Point questions: First, it seems to me that the AccessPoint Name for connection is listed under iPhone, but the connect button is grayed out? Mar 12 16:02:37 I don't know anything about the iphone Mar 12 16:04:50 Let me ask this way: how to connect to BBBw wifi access point? Mar 12 16:05:22 as far as I know you normally can just connect to it like any other wifi network Mar 12 16:14:49 there's nothing special about the access point it sets up... it's just an access point, like any other Mar 12 16:16:12 I am uploading images for you to see. Mar 12 16:37:23 https://drive.google.com/file/d/1nk2ChWmRzJ8_4XwM8fiPbvI2ThO4n0kx/view?usp=sharing Mar 12 16:37:55 https://drive.google.com/file/d/12-G3kQNyx9ekuIrIC2RjAOJydCzjPDnQ/view?usp=sharing Mar 12 16:38:09 I hope you can access the images Mar 12 16:40:20 The first image shows two BBBw Access Points, the next image shows to connect. But the Connect Button is disabled. Don't know how to enable it. Other Access Points are able to connect. Mar 12 16:41:06 ehm, it's very obviously waiting for you to enter the wifi password (default "BeagleBone", you can change it in /etc/default/bb-wl18xx) Mar 12 16:42:01 I entered pwd. And Waited for very long time. It doesn't highlight the button Mar 12 16:43:21 I tried on iPhone and Android Phone. As I said, other Access Points listed, I can connect to (Connect Button will turn on) Mar 12 16:45:11 like I said I don't know anything about iphone, but based on past experience I'm leaning towards assuming you're just doing something wrong :P Mar 12 16:45:31 other people have no problem connecting to the beaglebone's access point Mar 12 16:45:42 Also I found that after sleep-wake up, the access point will not be listed. It I reboot the BBBw, it appears again. ( I may need to do several times to confirm what I just said) Mar 12 16:47:31 you probably shouldn't try to enter sleep while the access point is enabled anyway, turn if off (systemctl stop hostapd) before entering sleep and back on (systemctl start hostapd) after resume Mar 12 16:47:40 Do you have any resources or links that related to BBBw Access Point setup, such as how the name is assigned, what IP associated to to proxy, etc. Mar 12 16:48:02 I already mentioned the config file Mar 12 16:51:53 The default password for AP is temppwd, which is the same as debian login. If I change debian password, is the password for AP automatically changed to the new passsword or it is still temppwd? Mar 12 16:52:10 the default password for the AP is not temppwd Mar 12 16:52:20 what is it? Mar 12 16:52:24 I literally just mentioned the default password Mar 12 16:52:30 as well as the location where it is configured Mar 12 16:52:43 I'm kinda fed up with you not reading what I'm saying when I'm answering your questions Mar 12 16:53:08 17:41 <@zmatt> ehm, it's very obviously waiting for you to enter the wifi password (default "BeagleBone", you can change it in /etc/default/bb-wl18xx) Mar 12 16:54:22 minimum wifi password length is 8 characters, which is why the iphone would not let you attempt to connect when you entered "temppwd" (which is only 7 characters) Mar 12 16:54:56 at least I think the minimum is 8 Mar 12 16:55:26 Uh, it is because password. Now connect is enabled. Thank you **** ENDING LOGGING AT Sat Mar 13 03:01:36 2021