**** BEGIN LOGGING AT Mon Jan 28 02:59:57 2019 Jan 28 09:35:04 How can i generate the clock of 3Khz on timer7(P8_8)pin of beaglebone. Jan 28 14:00:26 Anyone experienced in manage UART from shell ? Jan 28 14:02:20 write and consequentially read is a mess .... Jan 28 14:04:53 told you so Jan 28 14:05:17 using an uart from the shell *is* a mess Jan 28 14:06:03 three stupid commands... a pair of stupis answers..... a mess.... Jan 28 14:06:21 usin minicom , one shot one kill Jan 28 14:07:17 it should still be perfectly feasible using echo and read, as long as you can formulate proper terminating condition for the read and never lose sync Jan 28 14:07:51 but any mistake in that and you'll either hang for ever, or lose sync and as a result read the wrong data Jan 28 14:07:54 Hi everyone Jan 28 14:08:16 I need informations about capes for beaglebone x15 Jan 28 14:08:22 Can someone help me? Jan 28 14:08:49 I have to make a step backward from the "write into a file", just simple cat/read to console doesn't work, it seems something remain stuck into the open serial Jan 28 14:08:59 you mean about expansion boards for the beageboard-x15 :P (there is no "beaglebone-x15", and the beagleboard-x15 doesn't support capes) Jan 28 14:09:28 fred__tv: if it remains stuck then you have the wrong condition for terminating the read Jan 28 14:09:44 fred__tv: the read needs to know when to stop reading, it can't guess Jan 28 14:09:48 running minicom again and typing command gives back ERROR , the next command is ok Jan 28 14:10:00 then you're probably also sending the command wrong Jan 28 14:10:51 if I'd have to guess, it is expecting the command to be terminated by CR (\r) instead of LF (\n) Jan 28 14:11:15 i.e. when sending command the first time from shell , the expected answer is back , next something hangs.. Jan 28 14:11:27 hmm Jan 28 14:11:28 tried both Jan 28 14:12:11 oh actually, probably you're sending '\n' and the tty layer transforms that into "\r\n" undesiredly Jan 28 14:12:47 and the device sees the \r as terminating command, but thinks the '\n' is part of the next command which is unrecognized as a result Jan 28 14:13:10 i have tried also some stty options to override/transform new-line/CR/LF no luck Jan 28 14:14:03 with minicom I can try all the typing errors I want, the answer is ERRROR but the next right command has the right answer... Jan 28 14:14:17 well then somehow you're still sending garbage after the command Jan 28 14:15:38 also, with minicom open via SSH and typing echo 'command' > /ded/ttyO1 on beagle's keyboard/LCD I always get the right answer on minicom Jan 28 14:16:20 that is kind of interesting Jan 28 14:16:30 but dunno :) Jan 28 14:16:46 try using pyserial or such, it probably configures the port in a sane way just like minicom does Jan 28 14:16:47 it seems the serial kept opened by shell adds the problem Jan 28 14:17:21 I've seen somwhere to use two different FD Jan 28 14:17:47 exec 4<$tty 5>$tty Jan 28 14:17:55 that's pointless Jan 28 14:17:59 using one fd should be done Jan 28 14:18:32 in fact you suggest exec 4<>$tty Jan 28 14:18:40 do try, after opening: stty raw <&4 (or whatever fd you use) Jan 28 14:19:13 I've tried it before opening.... Jan 28 14:19:15 *should be fine Jan 28 14:19:19 thank you Jan 28 14:19:31 let me try Jan 28 14:20:43 maybe stty raw -echo since I don't know if raw implies -echo Jan 28 14:20:53 and echo would definitely be a great way to mess up the next command Jan 28 14:21:15 you could also use stty -a to dump the settings when minicom is open, and compare that with the settings you have Jan 28 14:22:24 what's the difference between <&4 and >&4 ?? Jan 28 14:22:35 > redirects output, < redirects input Jan 28 14:22:43 stty operates on its input file descriptor Jan 28 14:23:33 but for the command I have to use >&4 Jan 28 14:23:40 isn't it ? Jan 28 14:23:44 of course Jan 28 14:24:04 commands like echo and printf write to their output file descriptor Jan 28 14:24:16 so that's what you want to redirect to &4 Jan 28 14:24:33 look : I'm using this script : Jan 28 14:25:18 https://pastebin.com/JgZdmMws Jan 28 14:25:34 The first time it runs I get the right answer Jan 28 14:25:57 the second time I get "reply is ERROR" Jan 28 14:26:30 note: echo already adds a newline and doesn't interpret escape-sequences (unless you pass the -e option) Jan 28 14:26:43 so you're literally writing ver\n followed by a newline Jan 28 14:26:54 and like I said, try adding -echo to the stty options Jan 28 14:27:50 you mean ver\n is ver\n and not ver follower by newline ?? :-((( Jan 28 14:28:07 *followed Jan 28 14:28:28 if you want to interpret escape sequences, use echo -e or printf Jan 28 14:28:41 how do I add newline ? Jan 28 14:28:44 also, if you don't want to implicitly add a newline, use echo -n or printf Jan 28 14:28:51 (or cr/lf) Jan 28 14:29:00 e.g. echo -ne 'ver\n' is equivalent or echo 'ver' Jan 28 14:29:08 *equivalent to Jan 28 14:29:41 echo -ne 'ver\r' would send a CR instead of an LF Jan 28 14:29:57 trying Jan 28 14:30:09 but first try adding -echo to the stty options Jan 28 14:31:23 where should I send the beer ??? :-))) Jan 28 14:31:38 hehe, I don't drink alcohol, but thanks Jan 28 14:39:26 ver\n returns one row answer, now I need to read an answer composed by a number of rows (that I know) Jan 28 14:39:52 can "read" count rows nimber ? Jan 28 14:39:57 until it says OK right? I gave a command for that last time Jan 28 14:40:34 unfortunately no, there are other OK in between... Jan 28 14:41:43 sequence : coomand 1 --- answer OK command 2 --- answer OK command 3 --- N rows OK Jan 28 14:42:08 so that's fine then right? after each command, read until you get OK or ERROR Jan 28 14:44:22 https://ibin.co/4V4oP8Z0j3pO.jpg Jan 28 14:45:14 I don't know what you think I should be able to tell from this screenshot Jan 28 14:45:41 first and second commands return simpli an OK , I need to read (and write into file) the answer of third command Jan 28 14:46:08 okay, so what's the problem? you just said it gives a number of rows followed by OK Jan 28 14:46:35 just be sure to consume the output of *each* command after issuing the command, including those commands that only give OK in reply Jan 28 14:46:54 but when does "read" start to read ?? Jan 28 14:47:44 I don't know what you mean. all data received on the input is a single stream that's consumed by the read commands Jan 28 14:47:54 the exact timing of when data arrives is not important Jan 28 14:47:56 Or better , how tell read to end reading ? Jan 28 14:48:29 I already explained this last time, read will by default read until newline but it has a bunch of options to change its terminating condition Jan 28 14:48:58 if the output consists of lines, then you don't need those options Jan 28 14:49:29 if, like you said, the output consists of multiple lines of values followed by a line of OK then you can use the loop I gave last time Jan 28 14:49:58 this is the output: Jan 28 14:50:36 just make sure to consume the output of each command, otherwise you'll lose track of which response belongs to the most recent command Jan 28 14:50:49 https://pastebin.com/k9GnReyh Jan 28 14:51:02 (also if you don't wait for a reply, there's a risk that commands might get lost, depending on how much the device is capable of buffering) Jan 28 14:51:30 if those OKs are from the previous two commands, then you neglected to wait for OK after each of those Jan 28 14:53:00 yes, the first two OK from first two command (that are setting commands) the third command requests a reading Jan 28 14:54:35 i blindly issue the first two commands Jan 28 14:55:01 but I need the third one answer only Jan 28 14:55:09 https://pastebin.com/icF6c6Wh Jan 28 14:55:31 this is assuming each command ends in OK or ERROR Jan 28 14:55:39 if that's not true then you'll need to fiddle Jan 28 14:56:57 checking.. Jan 28 14:58:50 (it is not clear to me from your description whether the "ver" response ends in OK. if not then you may need to treat it specially Jan 28 14:58:53 ) Jan 28 14:59:32 no, forgive ver I don't need it Jan 28 14:59:54 It hangs after the first OK returned by first command.... Jan 28 15:01:11 I should ignore two first OK (it's just a confirmation given back...) Jan 28 15:08:36 uhh what? each command gives only one OK right? Jan 28 15:09:35 ohh, if it hangs waiting for OK, try adding igncr to the stty options Jan 28 15:09:48 the serial device probably sends OK\r\n Jan 28 15:09:53 the read will split on \n Jan 28 15:09:59 so it'll actually read "OK\r" Jan 28 15:10:02 which doesn't equal "OK" Jan 28 15:10:08 hence the loop never terminates Jan 28 15:10:21 the igncr will ignore CR on input Jan 28 15:12:06 It hangs after : Jan 28 15:12:08 command: FQ14500000n Jan 28 15:12:08 data: OK Jan 28 15:12:23 exactly, it doesn't recognize OK as end of command Jan 28 15:12:37 which means it's not just "OK" Jan 28 15:12:44 right Jan 28 15:12:45 my guess is that it's "OK\r" Jan 28 15:12:59 I suppose too Jan 28 15:12:59 which would be fixed by adding igncr to the stty options Jan 28 15:14:54 same thing Jan 28 15:16:03 If it would be OK\r\n ? Jan 28 15:16:13 try replacing echo "data: $line" with echo -n "$line" | hexdump -C Jan 28 15:16:19 to see what it's actually sending Jan 28 15:16:27 read will already strip off the \n Jan 28 15:18:15 command: FQ14500000n Jan 28 15:18:15 00000000 4f 4b 0d |OK.| Jan 28 15:18:15 00000003 Jan 28 15:18:44 huh, this is with igncr added to the stty options? (stty raw -echo igncr) Jan 28 15:19:45 f**k Jan 28 15:20:05 I had stty raw -echo -igncr Jan 28 15:20:10 with minus Jan 28 15:20:14 sillybeans Jan 28 15:20:26 works like a charm !!! Jan 28 15:21:22 If put first two commands before loop , would loop itself read only the third command output ? Jan 28 15:23:02 no, becaus it reads the buffer already filled with first two OKs Jan 28 15:23:30 like I said, you *have* to consume all output of each command Jan 28 15:23:32 use e.g. https://pastebin.com/icF6c6Wh Jan 28 15:25:18 incredible Jan 28 15:25:21 ! Jan 28 15:26:07 I would never have it done ! Jan 28 15:26:26 Orange juice then ? Jan 28 15:32:22 lol Jan 28 15:53:53 How was to use X environment via SSH ? Jan 28 16:01:33 ah export DISPLAY=:0 Jan 28 17:22:56 oof that external thread on the mailing list is giving me flashbacks Jan 28 17:23:07 ? Jan 28 17:23:31 there's a thread of pushy business people a bit out of their circle of competence who can't get anything going on the bbb Jan 28 17:23:46 ugh Jan 28 17:24:02 did you ever implement your own websockets zmatt? Jan 28 17:24:10 i know you were toying with it the last time we spoke Jan 28 17:25:51 I was indeed. it is temporarily shelved in favor of something higher-priority but I'll probably get back to it soon Jan 28 17:26:30 i thought you might be interetested in mosh shell or gravitational teleport Jan 28 17:26:34 i think they solve the same problem Jan 28 17:27:17 uhh, what on earth do those have to do with websockets? Jan 28 17:27:36 didn't this all start with getting access over port 80? Jan 28 17:27:42 err 443 Jan 28 17:27:45 as opposed to the ssh port Jan 28 17:27:51 so you were looking at http protocols Jan 28 17:27:53 that was my understanding Jan 28 17:28:15 i mean i don't really care one way or the other, you don't need to explain it to me Jan 28 17:29:45 I need websockets for multiple things, not just remote access, and the remote access has somewhat complicated requirements Jan 28 17:29:51 mosh is not even remotely useful Jan 28 17:30:26 gravitational teleport based on my 10 second glance also doesn't sound remotely useful Jan 28 17:31:00 Websockets! Jan 28 17:31:02 i think it's ssh'ing through firewalls, etc Jan 28 17:31:06 (teleport) Jan 28 17:31:11 but it may be heavy, not sure Jan 28 17:31:42 in case of remote access, it is the client (presumed to be behind a firewall that only allows outbound http/https) that needs to be remotely accessed Jan 28 17:33:36 teleport seems to be a giant thing that does nothing we really need and a ton we have no use for Jan 28 17:47:13 zmatt: I have a book on websockets programming. Do you want to view it? Jan 28 17:47:28 circa 2013? Jan 28 17:47:51 ehm, no I know how websockets work, but thanks Jan 28 17:48:03 Okay. No issue. Jan 28 17:48:21 It could give some insight on ideas you may have not thought about yet. Jan 28 17:49:08 ws:// instead of http:// right? Jan 28 17:49:40 I actually just got back to reading it. Jan 28 17:50:21 I think the people that made the book just wanted to promote a website or something but it has okay insight. Jan 28 21:09:21 Hello, I've been trying to make use of the PocketBeagle's SGX530 for some hardware acceleration, and I'm having trouble getting the drivers up and running. I was wondering if anyone had more recent experience than this email thread and the associated script that targets 3.14.y. https://beagleboard.narkive.com/oKmtcPRN/linux-gpu-driver. I've tried using the script with 4.14.y kernels, but it looks like some functions and/or entire dr Jan 28 21:09:49 the pocketbeagle? but it doesn't even have video output Jan 28 21:10:20 also, your message got cut off because it was too long ("it looks like some functions and/or entire dr") Jan 28 21:10:37 functions and/or entire drivers are missing. Sorry, haven't used IRC in a while. Jan 28 21:11:02 I'm aware, and I know it's a little bit crazy. Acceleration of a GPU-friendly algorithm is the goal, not traditional rendering Jan 28 21:11:16 ah I see. well, I have the sgx working on 4.14 kernel Jan 28 21:11:21 https://groups.google.com/d/msg/beagleboard/BEipC_SFjaE/zieEuZlfDwAJ Jan 28 21:12:33 Awesome! I used all my Google-fu, hoping to find an email like that, but unfortunately my Google-fu came up short. Jan 28 21:12:51 note also that I think rcn packages the kernel driver for ti kernels Jan 28 21:12:58 so you only need to worry about the userspace stuff Jan 28 21:13:32 you can try my hacky debian packages for that: https://liktaanjeneus.nl/sgx/ Jan 28 21:13:44 they're not entirely uptodate, but probably still work fine Jan 28 21:14:55 the package for the kernel module is called ti-sgx-ti335x-modules-$VERSION, e.g. ti-sgx-ti335x-modules-4.14.94-ti-r91 Jan 28 21:15:50 that's for the latest 4.14-ti series kernel Jan 28 21:16:24 Ah ok. Did Imagination Technologies finally decide to play nice or something? I thought that full driver support used to required building from source because of a no-redistribute license Jan 28 21:16:52 I'm not aware of there even being a "no-redistribute license" isue Jan 28 21:17:00 *ever Jan 28 21:17:28 the license for the closed-source libraries is pretty permissive (for a closed-source license) iirc Jan 28 21:18:36 Ah ok, who knows. https://beagleboard.narkive.com/oKmtcPRN/linux-gpu-driver made me think that once upon a time rcn wasn't allowed to distribute the drivers packaged, but was able to distribute their source? I don't really get it Jan 28 21:19:23 hmm, maybe the license did change, or maybe he was mistaken Jan 28 21:20:54 Reading that chain of emails you sent me, it looks like TI did some development work and that may be what changed Jan 28 21:21:15 pretty sure the old drivers allowed redistribution as well Jan 28 21:21:21 it would be pretty inane if they didn't Jan 28 21:21:22 Also, I feel dumb. I looked in the bb-kernel repo, was confused because it was empty, and missed that the sgx script is in fact there on 4.4 branches Jan 28 21:21:36 that script is for the old drivers though, not the new ones Jan 28 21:21:58 if you want to build a bb-kernel that supports the new sgx drivers you have to do a bit more work Jan 28 21:22:15 What's the tradeoff at the moment? Jan 28 21:22:18 if you want to be done with low effort I suggest just installing the latest 4.14-ti series kernel and its associated sgx package Jan 28 21:22:31 "tradeoff" ? Jan 28 21:22:47 e.g. advantage of the new drivers Jan 28 21:23:39 I have no idea if the old drivers still work, they're completely unmaintained and last targeted kernel 3.14 Jan 28 21:23:45 I think the oldest set of drivers had two versions - fbdev and the full propriety ones, or something? Not really sure, spent a while reading through that stuff and it still doesn't make sense. And redistribution wasn't allowed, so someone created a script to pull the source and build it, thus not redistributing Jan 28 21:23:58 there's no sane reason to still use the old drivers Jan 28 21:24:16 I'll go the right way then Jan 28 21:24:16 iirc the old drivers also required weird kernel hacks as a result of using fbdev Jan 28 21:24:23 Sounds about right Jan 28 21:24:33 while the new drivers use the drm api and dma-buf buffer sharing Jan 28 21:24:47 It's the sort of development hell you wind up in when people refuse to open source things that should be open source Jan 28 21:24:58 The old drivers, that is Jan 28 21:25:10 well the kernel part is open source Jan 28 21:25:54 (I don't recommend actually looking at it though, since it'll make you want to gauge your eyes out with a spoon) Jan 28 21:26:41 Well yes, but that's a shim designed to as you so eloquently stated it, make you want to (and allow you to) gauge you eyes out with a spoon. probably a rusty one Jan 28 21:27:07 https://elinux.org/BeagleBoardDebian#SGX_BeagleBone.2FBeagleBone_Black to clarify, this is definitely outdated and refers to the old driver, yes? Jan 28 21:28:11 it does what the kernel part of a gpu driver is supposed to do: manage memory mapping into the gpu and into userspace, allow userspace to safely operate the gpu, and provide synchronization between gpu and display controller Jan 28 21:29:07 yes, "GFX" and "omaplfb" are both keywords that indicate it's about the old driver Jan 28 21:29:33 Ah ok. Some of the posts I came across talked about how some companies make as thin as shim as possible, basically just a communication channel, and leave the real work on the other side. Jan 28 21:30:22 that is pretty much what I said: the purpose of the kernel driver is to do the minimum amount of work needed to let userspace use the gpu Jan 28 21:30:47 *safely use the gpu Jan 28 21:31:06 that's the "direct" in Direct Rendering Infrastructure Jan 28 21:31:12 Fair enough. I see the merits, but I also see the downsides if done lazily Jan 28 21:32:01 basically there's no sane reason to do the (usually very complicated) translation from 3d api (e.g. opengl es 2) calls to gpu primitives in the kernel Jan 28 21:32:28 Right, there's hardware support for it nowadays? plus security, of course Jan 28 21:33:06 Windows has had a CVE due to a buffer overflow in font rendering happening in the kernel, because it's Windows Jan 28 21:33:27 I'm not sure what you mean... hardware support for what? Jan 28 21:33:42 For translating opengl es2 to gpu primitives Jan 28 21:33:46 or is that in userspace? Jan 28 21:34:03 that doesn't make any sense, with "gpu primitives" I mean whatever the hardware needs/expects Jan 28 21:34:59 What I was trying to ask/clarify is it that translation doesn't happen in the kernel. Got that bit. Does it happen in userspace, or on the GPU side of things? Jan 28 21:35:02 in theory the hardware could be designed to directly take primitives of some 3d API as input (though then the question becomes, which of the several APIs?), but that's not what's done in practice Jan 28 21:35:28 userspace Jan 28 21:36:36 Oh, ok. Duh. I should have already known that, because that's been around since X windows came onto the scene, yes? Jan 28 21:38:08 not sure how 3d was done before DRI, but presumably it was done entirely in the X server back then Jan 28 21:38:21 since it had exclusive control over the gpu Jan 28 21:41:19 I tend to stay more on the networking side of things, the graphics side is a bit out of my comfort zone. But yeah, historically it was done entirely in X, including rendering. iirc, there are even still tiny bits of the primitive graphics that got replaced basically immediately still stuck in the core of X because of backwards compatibility. Getting back to a reference point I know something about made things make much more sense al Jan 28 21:41:48 cutoff after "much more sense al" Jan 28 21:42:22 btw I just checked, both old and new drivers are licensed under TSPA, which allows unlimited redistribution Jan 28 21:43:39 the rest of the sentence was just "all of a sudden" Jan 28 21:44:05 https://github.com/joelagnel/meta-ti/blob/master/licenses/TI-TSPA Jan 28 21:44:57 Weird, not sure why I thought otherwise. maybe some of it fell under Imagination Technology's less friendly licenses? All I know is that at one point people were forced to build from source for some reason Jan 28 21:45:17 I suspect it was just misunderstanding Jan 28 21:46:25 anyway, my recommendation is that you install use the 4.14.94-ti-r91 kernel and sgx modules package in combination with my userspace packages Jan 28 21:46:37 hopefully that simply works out of the box Jan 28 21:47:02 Quite possibly, Imagination Technology doesn't seem too friendly to open source. Trying it now, thanks a ton! Jan 28 21:47:16 I just have to figure out how the hell I'm gonna test it since it doesn't have a video out lol Jan 28 21:47:25 iirc my package creates a service file but doesn't arrange for it to start automatically at boot, it expects to be pulled in as dependency for whatever service needs 3d graphics Jan 28 21:48:57 https://pastebin.com/pKpzapZC Guesssing I should build from source and/or uninstall the normal wayland package? Jan 28 21:49:32 oh I forgot to run the perl script, that's probably important Jan 28 21:49:42 xorg was installed? what image are you running? Jan 28 21:50:02 you should not have any wayland, x11, or mesa stuff installed Jan 28 21:50:32 D'oh. I installed glxgears Jan 28 21:50:41 to try to see if there were already drivers on it Jan 28 21:51:19 Via mesa-utils Jan 28 21:53:56 Sorry, I swear I'm not usually this dumb. I've dual booted for years, but I've done relatively little embedded and graphics stuff, and I'm current up to my neck in both Jan 28 21:54:39 ah I was wondering why the iot image includes mesa-common-dev (and dependencies such as libdrm), but it's due to ti-opencl Jan 28 21:54:49 which doesn't belong on the beaglebone image in the first place, it's for the beagleboard-x15 Jan 28 21:56:24 if you start with a fresh iot image and apt-get purge ti-opencl, I suspect apt-get autoremove will get get rid of the rest Jan 28 21:58:18 On it. Honestly, I'm scripting everything and am eventually hopefully going to start with a fresh image for all the stuff I'm using Jan 28 21:58:27 this isn't the only device driver I've fought Jan 28 21:59:39 if you're comfortable with debian, you may want to start with a console image rather than the iot image Jan 28 22:00:04 which is a relatively minimal debian system for people who prefer to just install the stuff they want Jan 28 22:00:20 Yeah, I probably will. Group project, I wasn't the one who installed the initial image. Jan 28 22:00:28 My personal favorite for a driver nightmare is when the code is open source, packages are available for Ubuntu, but they don't want to bother with arm packages, source packages, or debian packages Jan 28 22:00:50 zmatt: why link to some random fork on github? Jan 28 22:00:51 you can find the console image here btw: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Snapshot_console Jan 28 22:01:00 denix: for what? Jan 28 22:03:48 zmatt: in this case the license. but just in general, shouldn't use the first found link to github Jan 28 22:04:59 denix: that's exactly what I do when it really doesn't matter, such as in this case Jan 28 22:06:04 zmatt: heh, then we get people claiming it's all outdated, when in reality they are looking at some random form on github that hasn't been updated in years Jan 28 22:06:41 ... it's a license Jan 28 22:07:00 zmatt: maybe it's less important for this particular case with the license file. but did you know TI has switched from TSPA to TFL couple years ago? Jan 28 22:07:28 well not for the stuff I was talking about Jan 28 22:07:36 zmatt: in reality it's pretty much the same though :) Jan 28 22:08:29 if the first page of google results included an authoritive-looking page at ti.com I would have linked that, but google just found random manifests and an e2e post Jan 28 22:09:16 therefore I linked to the first result, which was the license text I wanted to link to Jan 28 22:11:04 zmatt: yeah, I get it, I can't compete with github SEO :) Jan 28 22:11:56 well the fact that random shit at ti.com is found more relevant than the actual license text simply means ti just fucked up their searchability Jan 28 22:11:56 zmatt: btw, SGX kernel driver is GPL. but libgles user-space blob is TSPA/TFL Jan 28 22:12:16 I'm aware of that, I was talking about the userspace libs Jan 28 22:12:23 (I mentioned the kernel driver is open source) Jan 28 22:13:30 zmatt: ok, I'm butting out now, sorry... :) Jan 28 22:13:52 :) Jan 28 22:14:32 zmatt: and, yeah, search is a beach. I wonder is there's anyone in TI responsible for SEO... Jan 28 22:14:48 s/beach/bitch/g, d'oh Jan 28 22:16:17 heh Jan 28 22:16:40 most likely the actual documents are marked as no-index or something like that Jan 28 22:16:47 that's the only plausible explanation I can think of Jan 28 22:16:51 The horror... to remove everything, and I haven't event checked if it works yet: Jan 28 22:16:52 sudo apt --fix-broken purge libgles2-mesa libqt5* mesa* qt5* lxqt* qterminal pcmanfm-qt liblxqt* libdbusmenu-qt5-2 libqterm* libsysstat* va-driver-all vdpau-driver-all libkf5* libfm-qt3 Jan 28 22:17:17 Cgettys: okay this doesn't sound like you even started with the iot image Jan 28 22:17:28 did you start with the lxqt image?? Jan 28 22:17:37 if so, realy just start with downloading a new image Jan 28 22:17:51 that'll probably be faster and easier than trying to purge all the crap Jan 28 22:17:53 It was the iot image I think, tho I didn't personally install it Jan 28 22:17:57 already done :P Jan 28 22:18:06 no, that crap isn't in the iot image Jan 28 22:18:24 Well it was after stuff was installed and removed Jan 28 22:18:35 this project has been through a lot of software Jan 28 22:18:57 you wouldn't have lxqt, qterminal, pcmanfm-qt and such installed by accident as dependencies Jan 28 22:19:14 it seems far more likely it was simply the lxqt image to begin with Jan 28 22:20:50 Possible. Again, not (directly) my fault if they did start with it Jan 28 22:23:01 cat /proc/version gives: Linux version 4.14.94-ti-r91 (root@w6-imx6q-wandboard-2gb) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP PREEMPT Sat Jan 26 19:23:53 UTC 2019 Jan 28 22:23:16 I wasn't assigning fault, I was simply observing Jan 28 22:23:23 Fair enough Jan 28 22:25:35 Yeah you're right, it's flatout the full BB debian image Jan 28 22:26:00 removing libdrm2 and everything that depends on it would probably also help with cleanup (even though you'll then need to install libdrm2 again since my userspace package depends on it) Jan 28 22:26:22 but really, I strongly suggest getting a fresh iot or console image instead Jan 28 22:27:41 I definitely am going to tomorrow, but actually I mean it. Right now I'm just hacking on this image because I know I'm gonna screw it up somehow anyway lol. Also because I'm almost done fighting this for the day Jan 28 22:29:07 also, the following packages are bbx15-specific so I suggest removing them on the beaglebone: firmware-am57xx-opencl-monitor ipumm-dra7xx-installer ti-opencl tiomapconf vpdma-dra7xx-installer Jan 28 22:31:30 Thanks for the tip, no need for unused packages cluttering the sd card Jan 28 22:33:34 Sigh... any thoughts? https://pastebin.com/eyZHd7QK Jan 28 22:34:17 or is that just a symptom of no video out? Jan 28 22:36:07 oh right you'll need to enable tilcdc and sgx using a device tree overlay Jan 28 22:36:27 they won't be enabled by default on a pocket beagle Jan 28 22:36:49 grab my https://github.com/mvduin/overlay-utils Jan 28 22:37:09 create enable-video.dtsi with the following two lines: Jan 28 22:37:12 That, I can do. I've been messing around with device tree all last week for another piece of hardware Jan 28 22:37:19 ok Jan 28 22:37:29 just status="enabled" on &lcdc and &sgx Jan 28 22:42:46 Incidentally, a piece of hardware I don't have yet, so I can't check if it works. But at least the device tree overlay I tweaked based on examples loads and doesn't keep it from booting, so I can't be completely clueless Jan 28 22:43:07 lol Jan 28 22:43:46 Luckily, it's more TI hardware which is known to work on both the PB and the BBB, it's just the config that's weird (tlv320aic3104 stereo audio codec, if you're curious) Jan 28 22:44:43 in case you're interested btw, my overlay-utils repo uses a perl script to convert normal device tree fragments like you'd find in the main dts ( &foo { ... }; ) into the obnoxious structure required for overlays ( / { fragment@N { target = <&foo>; __overlay__ { ... }; }; }; ) Jan 28 22:45:09 (after preprocessing and before running it through dtc) Jan 28 22:45:13 That's pretty cool Jan 28 22:46:19 Haven't ever used perl, but I've used some Chez-Scheme (it's related to lisp) Jan 28 22:47:27 kmscube gives the same error, but.... dmesg gives me this now: Jan 28 22:47:28 [ 62.221566] pvrsrvkm: loading out-of-tree module taints kernel. [ 62.419181] [drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 1 Jan 28 22:47:33 I don't know if it gave me that before Jan 28 22:47:49 have you started the service installed by my sgx userspace package? Jan 28 22:48:21 oh right. Duh. Good catch Jan 28 22:48:39 unless it starts automatically that is, I don't 100% remember Jan 28 22:49:33 yeah it doesn't Jan 28 22:50:26 Started it. Got one more line in dmesg Jan 28 22:50:27 [ 406.614613] PVR_K: UM DDK-(3699939) and KM DDK-(3699939) match. [ OK ] Jan 28 22:50:43 sounds good Jan 28 22:51:28 But same error from kmscube. at this point, maybe lack of display? Jan 28 22:51:56 could be, try forcing the video mode via kernel parameters (I think /boot/uEnv.txt contains an example in comments) Jan 28 22:52:25 oh that might not work actually, though I guess it's still worth a try Jan 28 22:52:37 what error does kmscube give exactly? Jan 28 22:52:56 do /dev/dri/ devices show up for lcdc and sgx ? Jan 28 22:56:19 debian@beaglebone:~$ ls /dev/dri gives: card0 card1 renderD128 sgx Jan 28 22:56:25 ok good Jan 28 22:56:32 kmscube gives: https://pastebin.com/eyZHd7QK Jan 28 22:56:48 that's odd Jan 28 22:57:34 so it can't drmOpen the device? weird Jan 28 22:57:46 maybe strace to see what's going on Jan 28 22:58:38 Is this the line you mean for uEnv.txt? cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e Jan 28 22:59:01 yeah Jan 28 23:04:45 stat64("/dev/dri/card6", 0xbef13018) = -1 ENOENT (No such file or directory) Jan 28 23:04:50 is the error I get from strace Jan 28 23:04:57 after rebooting with the cmdline boot flags Jan 28 23:05:10 nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0 stat64("/dev/dri/card6", 0xbef13018) = -1 ENOENT (No such file or directory) Jan 28 23:05:13 over and over Jan 28 23:05:15 those three lines Jan 28 23:05:20 nanosleep({tv_sec=0, tv_nsec=20000}, NULL) = 0 stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0 stat64("/dev/dri/card6", 0xbef13018) = -1 ENOENT (No such file or directory) Jan 28 23:05:45 I'll pastebin the whole things Jan 28 23:06:12 card6 ?? what? Jan 28 23:06:29 is libdrm drunk? Jan 28 23:06:30 Reran it, card 4 now Jan 28 23:06:49 https://pastebin.com/iDpjea8S Jan 28 23:07:42 ah no it opens the devices sequentially Jan 28 23:08:14 I was looking thru hte pastebin and had just realized that myself Jan 28 23:08:18 with some retries Jan 28 23:08:39 sp it did open both card0 and card1 but is somehow not satisfied with the response from DRM_IOCTL_VERSION ? weird Jan 28 23:09:56 just checking, one of the two devices *is* tilcdc right? and not sgx + vgem or something silly like that? Jan 28 23:10:34 maybe check what the /sys/class/drm/card[01] symlinks point to Jan 28 23:12:16 lrwxrwxrwx 1 root root 0 Jan 28 23:00 card0 -> ../../devices/virtual/drm/card0 lrwxrwxrwx 1 root root 0 Jan 28 23:11 8 Jan 28 23:12:21 card1 -> ../../devices/platform/ocp/56000000.sgx/drm/card1 lrwxrwxrwx 1 root root Jan 28 23:12:22 0 Jan 28 23:11 renderD128 -> ../../devices/platform/ocp/56000000.sgx/drm/renderD12 Jan 28 23:12:32 it actually *is* vgem -.- Jan 28 23:12:42 what does that mean? Jan 28 23:12:50 you did set status="enabled"; on &lcdc ? Jan 28 23:12:58 yeah Jan 28 23:13:39 oof, it might then actually need to think there's an output attached Jan 28 23:14:18 Like this yes: https://pastebin.com/5k4KwnJv rest of the file omitted Jan 28 23:15:11 It could also be the rest of my overlay messing stuff up. It makes use of the mcasp0 unit which is used for hdmi audio usually Jan 28 23:15:22 https://pastebin.com/KrD2Uwpz here's a panel declaration you could stuff into an overlay Jan 28 23:15:29 the pocketbeagle has no hdmi Jan 28 23:15:58 I know Jan 28 23:16:01 the hardware is still there Jan 28 23:16:10 no it isn't, there's no hdmi framer Jan 28 23:16:15 nor audio osc Jan 28 23:16:29 Well shit. Not even I2S? Jan 28 23:16:46 Pretty sure there's I2S Jan 28 23:17:06 you can use i2s, assuming the pins are available (I'm not hugely familiar with the pocketbeagle's pinout) Jan 28 23:17:14 but you'll need an externally provided clock Jan 28 23:17:24 Yeah the pins are, that's what I'm using for audio Jan 28 23:17:30 Think the mcasp0 is still there Jan 28 23:17:45 mcasp0 itself is a peripheral on the SoC, so obviously it is Jan 28 23:18:10 Ok, phew. That's where I'm getting all the audio capabilities Jan 28 23:19:52 I thought it was used in conjunction with the hdmi framer to provide hdmi audio, but I might be wrong Jan 28 23:20:21 it is, on the beaglebone black, but that's irrelevant on the pocketbeagle which has no hdmi framer Jan 28 23:20:44 Makes sense. I got my causation backwards Jan 28 23:22:05 Some of this stuff is kind of sketchily documented (due to it being a TI chip with other IP in it, inside an Octavo Systems Package, on a Beaglebone organization board, kinda to be expected) Jan 28 23:22:18 just because there are so many layers of customization Jan 28 23:22:38 so I'm reverse engineering capabilities based on capes and documentation Jan 28 23:22:40 well all of those parts are pretty well documented Jan 28 23:23:41 the pocketbeagle is pretty much the osd3358 with some connectors though Jan 28 23:23:43 Yeah, they are, for which I am very thankful. But by the time you get to the pocket beagle, few people have necessarily tried to say, get it to do audio (Bela.io is where I found the most useful info) Jan 28 23:24:34 and yeah, that's the whole point here. Eventually, we're hoping to fabricate our own board for this project... he... he... that'll be fun... right?? Jan 28 23:26:42 \o/ Jan 28 23:27:05 honestly if you use the osd335x then it shouldn't be too hard? Jan 28 23:27:16 it has all the hard parts inside already Jan 28 23:34:02 Yeah, it's everything outside of it that isn't required for the pocketbeagle itself that's a nuisance Jan 28 23:34:06 https://pastebin.com/Uvpj0dVG Jan 28 23:34:22 does that look right ish? just gae you the whole file instead of snipping hte snippet Jan 28 23:34:52 I'm gonna convert it into your easy way at some point, because that's pretty neat and simple, but for now I just made it an oldschool overlay Jan 28 23:36:14 well the clocking stuff doesn't, since you seem to be declaring the use of the beaglebone's audio osc which you don't have Jan 28 23:36:39 Will keep that in mind. I'll have to feed in an external oscilliator Jan 28 23:36:46 the lcd panel spec fragment is nonsense Jan 28 23:37:04 &lcd-panel is a syntax error even Jan 28 23:37:16 and would be a nonexistent label otherwise Jan 28 23:38:11 I hadn't had to write one completely from scratch yet. Jan 28 23:38:15 you need a fragment with target-path = "/"; __overlay__ { lcd-panel { ... }; }; Jan 28 23:38:21 oh Jan 28 23:38:23 I'm dumb Jan 28 23:38:34 right it's new hardware not overlaying existing Jan 28 23:39:06 &label is a reference to an existing node labeled with label: Jan 28 23:39:40 lcd-panel in this case is the name of a new child node of the root. it has no label Jan 28 23:40:35 labels have to be valid C identifiers, which is why &lcd-panel would be a syntax error. if there were a need to refer to it globally (there isn't) you'd use e.g. lcd_panel: lcd-panel { ... }; Jan 28 23:40:36 That makes sense. I swear, I've been reading all the documentation I can find. Issue is, at least half of it is for the older dead overlay system Jan 28 23:41:01 target = or target-path =? Jan 28 23:41:11 the only difference between the old and new overlays systems is how/when they get loaded, not their content Jan 28 23:41:38 Oh. I feel even dumber Jan 28 23:41:51 I didn't really get that from what I read about the two systems Jan 28 23:41:54 target = <&label>; or target-path = "/path"; Jan 28 23:42:05 in this case you want to target the path / Jan 28 23:42:07 explains why nobody bothered to redo their tutorials Jan 28 23:42:21 Right, makes sense, different convention to distinguish it Jan 28 23:42:36 different property name since how else would it be able to tell? Jan 28 23:42:43 the content of properties in dt is untyped Jan 28 23:42:46 Right Jan 28 23:43:36 just like the contents of files, the contents of properties is just a sequence of bytes. you need external knowledge to interpret it Jan 28 23:44:10 https://pastebin.com/XC8vB33d Jan 28 23:46:29 I have saved that for reference Jan 28 23:46:48 Now, ignoring the invalid oscillator for now, does this look ok? https://pastebin.com/tqBwMXCf Jan 28 23:46:53 also ew @ using magic hex constant for pin configuration instead of using macros for readability Jan 28 23:47:37 I spot } without ; Jan 28 23:47:52 Agreed, someone else had done it that way and it's the right config so I didn't want to touch it Jan 28 23:48:24 maybe see if it compiles before asking me ;) Jan 28 23:48:39 Oh right duh Jan 28 23:48:48 Sorry, I was in the mindset that it would compile, but fail on boot Jan 28 23:49:50 I personally prefer creating an explicit simple-audio-card,dai-link node inside the sound node, like this: https://pastebin.com/VmHHXagD rather than dumping its contents with simple-audio-card, prefix into the sound node Jan 28 23:50:13 (this is newer syntax which also permits the sound node to specify more than one dai-link) Jan 28 23:50:37 Good to know Jan 28 23:51:50 Basically, what my goal was is to take the PB-compatible stuff the team behind Bela did for Bela Mini, strip away the PRU stuff they did because I don't need audiophile quality audio or the headaches it comes with, and thus simplify things abit Jan 28 23:51:55 hence the frankenstein monster Jan 28 23:52:19 Ok, built that time. So it maybe works Jan 28 23:53:11 pretty sure bela uses pru for low-latency stuff, has nothing to do with audio quality Jan 28 23:53:32 zmatt: accurate. Jan 28 23:53:48 yo jkridner[m] Jan 28 23:54:03 howdy Jan 28 23:54:10 sorry I've not been around Jan 28 23:54:22 * jkridner[m] needs to start trying to recruit for GSoC! Jan 28 23:54:38 bbb.io/gsoc Jan 28 23:54:50 They appear to be using it for low latency audio, at any rate Jan 28 23:55:21 unless I'm misunderstanding Jan 28 23:55:44 that's what I said Jan 28 23:57:04 Sorry, I'm being about as unclear as I ever am today... My point is instead of doing things the normal way they skip alsa and the normal sound stuff entirely afaik: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BELA-B2.dts Jan 28 23:57:24 because latency. Jan 28 23:57:54 Which is all good, and which makes sense for their application, and it's possible I'll end up wanting to do something like that Jan 28 23:58:27 but at the moment I wanted things to be easy. So I tried to smash together the normal sound card setup with the pinmuxing etc for the pocketbeagle Jan 28 23:58:56 sounds sane enough Jan 28 23:59:12 Except hte part where I left in the bit for a non-existent oscillator Jan 28 23:59:31 indeed Jan 28 23:59:38 trying to load module tilcdc...success. Jan 28 23:59:47 whatever the codec uses for its clock input should be specified in the DT instead Jan 29 00:00:28 e.g. if it has an oscillator, then you just want a fixed-clock node for it, not a gpio-gate-clock Jan 29 00:00:35 success \o/ Jan 29 00:01:08 Isn't line 80 of this https://pastebin.com/tqBwMXCf that? Jan 29 00:01:18 and then the other bit is beaglebone black specific? Jan 29 00:01:42 that declares a fixed osc yes, but you use it to derive a gpio-gated clock Jan 29 00:03:06 also, if mcasp is in slave mode then it has no use for the ahclkx pin Jan 29 00:03:50 and ahclkx is extremely unlikely to be an output in any situation (as the pinctrl seems to imply) Jan 29 00:04:56 (since mcasp on the am335x can only produce 24 MHz and quotients thereof, which is basically useless for audio purposes) Jan 29 00:05:26 Would ahclk make more sense? it was originally labeled as such, but that didn't make sense with the pinout as far as I could work out Jan 29 00:05:44 https://pastebin.com/MU6XLF0d it compiles, is that what the clock should look like? or a different frequency? Jan 29 00:06:15 "ahclk" does not exist, you probably mean either ahclkx or aclkx Jan 29 00:06:47 are you asking me what oscillator you connected to your codec? how should I know? :) Jan 29 00:06:53 Ok, so I was right about the mislabeling Jan 29 00:07:17 Well, if I connected an osc to my codec I'd be baffled since I don't have a PCB for it yet and it's surface-mount :P Jan 29 00:07:49 well how were you planning on connecting it in the first place? Jan 29 00:08:00 and it will need an osc Jan 29 00:08:12 (or at least a crystal, if it has an internal osc) Jan 29 00:09:20 PCB is getting made, that's just not my job. I'm preparing software support so that when the electrical engineering guy finishes that, I'm already ready Jan 29 00:09:21 why is your pinmux labeled with beaglebone pin identification instead of pocketbeagle pin identification? :P Jan 29 00:09:36 if you're making a DT then the schematic is very much relevant to you Jan 29 00:09:42 since the DT needs to describe the hardware Jan 29 00:10:52 True. but I know what the hardware is, and I'm working backwards to figure out what pins we can use when he has a chance to finish that Jan 29 00:11:01 I know, it's a mess Jan 29 00:11:10 https://pastebin.com/raw/37Vr51Wr here are some notes about mcasp and such btw Jan 29 00:12:08 (beware that not all configurations described there are supported by the linux driver currently) Jan 29 00:12:15 Good to know Jan 29 00:12:40 e.g. using independently-clocked tx and rx isn't Jan 29 00:12:51 And it's labeled with that because it's what I had as source Jan 29 00:13:21 https://goo.gl/Jkcg0w here's my pins spreadsheet Jan 29 00:13:25 I started with this: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BELA-B2.dts which as best I can tell, somehow supports both PB and BBB, although I've had a hard time finding much info Jan 29 00:14:06 the "Pocket brief" tab is probably most useful Jan 29 00:21:30 I'm honestly not sure A. what they were going after and B. what I'd want to do. I think I'm gonna call it a day and bug the electrical engineer tomorrow lol Jan 29 00:21:46 He has far more knowledge of oscillators than I do Jan 29 00:22:29 basically: unless he's happy with a 24 MHz clock from the pocketbeagle, he'll need to arrange for his own clocking needs Jan 29 00:22:58 (but you do need to know the details to declare them in DT) Jan 29 00:23:02 Isn't there a 1GHZ clock? for the cpu? though I guess it's not fixed rate Jan 29 00:23:40 and it's used for the cpu and nothing else Jan 29 00:24:00 Makes sense. not exactly a clock in the traditional sense, you don't want to use it to keep time lol Jan 29 00:24:18 Yeah, we just hadn't realized there wasn't an audio clock onboard, assumed it came along with the I2S output. Big mistake there. Thanks A. for saving me a lot of confusing with that Jan 29 00:24:19 overall it doesn't matter which clocks exist, the only one available for mcasp to generate clocks from is the 24 MHz main oscillator Jan 29 00:24:41 B. answering all my stupid questions and C. giving me so much good info about this stuff Jan 29 00:24:50 which is useless, which is exactly why the beaglebone black included an external audio osc Jan 29 00:24:58 (24.576 MHz) Jan 29 00:25:15 As well as an external codec I believe Jan 29 00:25:28 no Jan 29 00:25:34 no codec, just the hdmi framer Jan 29 00:25:48 Oh wait I'm thinking of the audio cape I think Jan 29 00:26:08 Oh and the hdmi framer provides the audio for the BBB? Jan 29 00:26:50 the bbb's only integrated audio output is via the hdmi output Jan 29 00:27:01 That's what I was trying to ask Jan 29 00:27:24 And then the audio cape if you get one provides line in and out via the same chip we're trying to use Jan 29 00:27:48 ok Jan 29 00:28:30 which means it probably disables hdmi audio Jan 29 00:28:51 but uses the same pins, along with the clock provided by the audio osc Jan 29 00:30:09 so, for clarity: the beagle itself only requires the audio master clock (provided via hclkx input) if it's going to act as master (clkx/fsx output), not if it's going to act as slave (clkx/fsx input) Jan 29 00:34:11 One more dumb question then - what's the difference in terms of capability, or does it just not matter? Jan 29 00:34:26 usually it doesn't really matter Jan 29 00:36:33 Ok, thanks so much for answering all my dumb questions. I'll be back at some point, either with more dumb questions and/or a finished project to show for it. Jan 29 00:36:43 :) Jan 29 00:38:32 Trust me, it'll be super cool in the end, assuming it works lol. Of course, it's significantly closer to working thanks to you. I could have spent all week trying to figure it out and I would have learned less than I did in the last couple hours. Jan 29 00:38:47 Have a great evening! Jan 29 00:39:04 Or morning, as case may be Jan 29 00:40:25 hehe, evening Jan 29 00:44:35 evening! Jan 29 00:44:59 I am still trying to get this BBBlue up and flying. Man, I am slow in this dept. Jan 29 00:45:36 I finally figured out, through guidance, that the two, separate connections from the LiPo can be used. Jan 29 00:45:42 They are not just for show. Jan 29 00:46:36 Is is possible to use a 12v adapter to charge my LiPo on the BBBlue? Jan 29 00:47:42 Or... Jan 29 00:48:11 Should I use a LiPo charger/balancer for the LiPo stuff and skip the BBBlue? Jan 29 00:48:30 have both available. Jan 29 00:48:52 Snert: Okay. That is what I thought but I was unsure about the balancer for the BBBlue. Jan 29 00:49:06 is your lipo a part of a charging board? Jan 29 00:49:21 charging board? Jan 29 00:49:24 usually the board docs will state acceptable charging levels Jan 29 00:49:30 Oh. Jan 29 00:50:10 I have a specific LiPo charger/balancer which alarms when the "time" is up. Jan 29 00:50:26 They have levels that need to be checked during charging. Jan 29 00:50:35 if it's a 1 cell lipo then there's really nothing to balance. Jan 29 00:50:45 Right. Jan 29 00:50:51 2S like the BBBlue uses. Jan 29 00:51:21 I was thinking that the BBBlue may charge but not balance. Jan 29 00:51:26 Is this a fact? Jan 29 00:51:55 it balances Jan 29 00:51:58 I guess only software could tell, right (in this case)? Jan 29 00:51:59 Oh? Jan 29 00:52:04 Cool. Jan 29 00:52:10 pretty sure I remember a balancer, lemme double-check Jan 29 00:52:14 Okay. Jan 29 00:52:19 Where are you looking? Jan 29 00:52:26 schematic Jan 29 00:52:29 Oh. Jan 29 00:52:39 yep it has a balancer Jan 29 00:52:41 I should pull that bad boy out. Schematics. Jan 29 00:52:44 Hmmm. Jan 29 00:53:18 So, it balances and charges via adapter or power source. Now, how do I know that it has balanced? Jan 29 00:53:46 Should I write some software to know? Jan 29 00:54:04 it just happens automatically, there are no software controls or readouts Jan 29 00:54:09 Okay. Jan 29 00:54:26 I think writing a source for this idea would be beneficial. Jan 29 00:54:34 But... Jan 29 00:54:49 I need to research a ton. I am in no way ready for that task. Jan 29 00:54:53 ? Jan 29 00:55:13 realistically speaking, what are you gonnadu if battery performance is degrading? Jan 29 00:55:22 You know...a Python script for reading the levels of the batteries. Jan 29 00:55:24 Charge! Jan 29 00:55:29 try a new lipo so might as well cut to the chase. Jan 29 00:55:37 Oh. Jan 29 00:55:48 what do you mean by "battery performance" Jan 29 00:56:03 performance less than expected over time. Jan 29 00:56:14 Still, typing up some source for a Python script would be nice for the community. Jan 29 00:56:29 "Look, this is your battery on the BBBlue!" Jan 29 00:56:48 Heh? Jan 29 00:57:01 the blue has no hardware to track battery charge (i.e. a column counter). it just has a voltage measurement circuit, but that's not very useful to determining battery charge Jan 29 00:57:11 Oh. Jan 29 00:57:19 Okay. No issue. Jan 29 00:57:26 enquiring minds wanna know. But armed with that knowledge...what can you do? Replace the lipo is about all. Jan 29 00:57:58 Yep. LiPo batteries are nice when they work. Jan 29 00:57:58 I'm not sure if set's actually talking about battery performance or just battery charge Jan 29 00:58:08 unless one wants to go whole hog and do component level repair of a bbb. Jan 29 00:58:17 Not me. Jan 29 00:58:43 Snert: I just figured out today that I can use both battery connections on the LiPo. Jan 29 00:59:03 I thought that they were only for balancing and charging. Jan 29 00:59:37 I can power two separate things at two separate times. Jan 29 00:59:51 Connect. Jan 29 01:00:00 or swap same lipo over to the other charging circuit. Jan 29 01:01:06 I'd just use an external charger and see if bad performance follows the lipo or the charger. Jan 29 01:01:45 Hey. Do LiPo batteries work like lead acid in they way they can be placed in parallel or series. Jan 29 01:01:47 ? Jan 29 01:02:31 Snert: No issue. My LiPo batteries have seen their existence. I will most likely need to replace them one day. Jan 29 01:02:47 They are expensive! Jan 29 01:03:22 ... Jan 29 01:03:57 I was thinking about it. If I use the 2S for the BBBlue, I could use the two, 2S LiPo batteries in series. Jan 29 01:04:26 that would double the voltage. Jan 29 01:04:30 Ooops. Jan 29 01:04:34 In parallel. Jan 29 01:04:47 that would make the run time double. Jan 29 01:04:56 so yep...you got that right. Jan 29 01:05:03 Right, that makes more sense. Jan 29 01:05:21 Run time double is better than a busted BBBlue. Jan 29 01:05:40 but I'd charge them seperately. I don't have a blue so I can't really read about that particular board. Jan 29 01:05:52 I understand. Jan 29 01:06:03 I could but I don't have one so heck with it. Jan 29 01:06:11 I just wanted to get up and running w/ this ArduCopter stuff. Jan 29 01:06:19 I'm used to lipo charging in the RC heli world. Jan 29 01:06:23 I got this idea from BBB.io. Jan 29 01:06:24 Oh. Jan 29 01:07:02 a good eye opener is one of the RC heli/drone forums. Tons of charging info there. Jan 29 01:07:11 It is for R/C stuff. I am adding a R/C idea mixed w/ Linux on the BBBlue. Many people, supposedly, have done it already. I wanted to try it out. Jan 29 01:07:24 custom build chargers.....series/parallel charging....etc. Jan 29 01:07:49 The BBBlue is a known board for that ArduPilot stuff. Jan 29 01:08:45 I got the software working on the BBBlue, I then damaged my power board, and then reassembled the solder joints on the power board. Jan 29 01:08:58 if you're into rolling your own lipos there's info about that too. Jan 29 01:08:59 Now, it is off to receiver land w/ the BBBlue soon. This is the final task. Jan 29 01:09:25 think about a seperate receiver battery pack. Jan 29 01:09:35 Right! Jan 29 01:09:41 That is what I thought so far. Jan 29 01:10:10 that "find me" beeper needs to work for an hour after it crashes into a tree. Jan 29 01:10:18 One battery for the receiver, one for the BBBlue, and one for the transmitter (obviously). Jan 29 01:10:31 Hmm. Jan 29 01:10:38 Crashes. Yum. Jan 29 01:10:44 Ha! Jan 29 01:11:26 Three batteries and a flying BBBlue makes me tingly inside. I cannot wait to test out this hardware. Jan 29 01:11:46 Snert: I have been trying this out for about a year now. Jan 29 01:11:58 it's great fun Jan 29 01:12:24 roof gutter inspections might be a payin' gig. Jan 29 01:12:46 Connection after connection, fail after fail, and I just got guidance on this dual purpose for both LiPo connection leads. Jan 29 01:12:48 just stay over the house in question....and hey.....you didn't charge him. Jan 29 01:13:07 Snert: I was going to make a book. Jan 29 01:13:20 What do you think? Jan 29 01:13:38 BBBlue! Jan 29 01:13:50 Well...see what info is in the forums and see if you're just duplicating work already done Jan 29 01:14:17 helifreak is a good site for that Jan 29 01:14:21 I want to add some cool stuff about the Capes but I am not sure yet. They are not production Capes yet. Jan 29 01:15:06 The only production Cape so far is the Robotics Cape and it is already a BBBlue. Jan 29 01:15:23 then you'll be the first with new info maybe :) ALways kinda nice. Jan 29 01:15:47 I have the same ole ideas as last year but it is w/ the BBBlue. Who knows? I could get the word out more. Jan 29 01:15:59 but serious man...there's 284,529 tons of lipo charging stuff out there. Jan 29 01:16:19 Okay. Snert: Where you big into R/C for a bit? Jan 29 01:16:33 I was but got out of it. Jan 29 01:16:35 Where = Were Jan 29 01:16:38 Oh. Jan 29 01:16:51 not enuff payback. Too many crashes. Jan 29 01:17:09 rotor heads (good ones) ain't cheap Jan 29 01:17:18 Snert: I bet that got expensive. I just want to loiter w/ my machine. Jan 29 01:17:28 Loitering BBBlue! Jan 29 01:17:43 yea and a drone means less crash cause it can just hover and be stable. Jan 29 01:17:50 more controllable Jan 29 01:18:12 a heli is like....woops...BLAMMO....blades flying..... Jan 29 01:18:28 No racing or fast movements. Hopefully, that ArduPilot stuff is all it is cracked up to be. Jan 29 01:18:30 Oh. Jan 29 01:18:34 wait 2weeks for parts. Jan 29 01:18:39 then crash again Jan 29 01:18:50 I have some bHeli ESCs. Is that a bad move? Jan 29 01:19:24 from the receiver's perspective...an ESC is just a servo. Same signals are used to drive them. Jan 29 01:19:51 Oh. Okay. PWM? Jan 29 01:20:31 you can put your esc on any receiver channel actually. Though the Tx is optomized for a particular channel with throttle functions. Jan 29 01:20:45 Oh. UART! Jan 29 01:21:30 I got this X8R from FrSky and a cheap FrSky transmitter. Jan 29 01:21:50 They said they would communicate. I have been unable to make them communicate so far. Jan 29 01:21:52 you could put an ESC on an bbb and drive it with PWM to move a motor if ya wanted to. Jan 29 01:22:01 Oh! Jan 29 01:22:10 That sounds like an interesting thing to do. Jan 29 01:22:47 yep it looks like a servo to a receiver. So if a bbb can drive a servo it can drive an ESC. Jan 29 01:23:22 Oh. Jan 29 01:23:34 nobody does that because around here it's motors/steppers and not much electronic communitating. Jan 29 01:23:38 The BBB can drive servos! Jan 29 01:23:49 Right. Jan 29 01:24:03 I get that idea. People want GUIs and cutting tools. Jan 29 01:24:56 I always wanted to use MachineKit w/ the BBB or related board. Jan 29 01:25:40 The info. seems accessible and ready to be used. I even found their GoogleGroups page via their homepage. Jan 29 01:26:39 Snert: Do you 3D print w/ the BBB? Jan 29 01:27:13 I was thinking...dang. If I can print w/ the BBB, I could use it for machining. Jan 29 01:27:14 nope not yet. Jan 29 01:27:32 I'm more into network monitoring/packets/traffic. Jan 29 01:27:48 and providing network services with bones. Jan 29 01:28:05 Oh. Jan 29 01:28:19 Like BBB Routers? Jan 29 01:28:44 dns dhcpd ntp kerberos ldap etc. Jan 29 01:28:50 Oh. Jan 29 01:28:51 Okay. Jan 29 01:29:03 So, do you use Gunicorn? Jan 29 01:29:06 little test beds for network services. Jan 29 01:29:19 No never heard of it. Jan 29 01:29:44 Oh. I found it the other day while trying to figure out how to host sites I built. Jan 29 01:30:23 For instance, I have this web address, I have the site, but I cannot serve this sucker. Jan 29 01:30:25 Blah! Jan 29 01:30:50 I tried uWSGI but failed. Jan 29 01:31:11 I'm an apache lover - I see gunicorn is a lite weight http server. Jan 29 01:31:31 I can use other (development) "brands" but not that uWSGI server yet. Jan 29 01:31:39 oh. Apache. Jan 29 01:31:47 which is cool I just need different options at times. And a full blown web server more fits my needs Jan 29 01:32:04 Oh. Jan 29 01:32:19 even if I trim it down and do not load alot of the apache modules I don't really need. Jan 29 01:32:37 Do you use Nginx w/ the BBB? Jan 29 01:33:07 no but it's on my list to check out. Home automation uses that alot. Jan 29 01:33:39 Snert: To tell the truth, I got scared of erasing the testing script from Nginx and making my own (in case my own script worked). Jan 29 01:33:54 I'm getting stray zigbee or z-wave trames with my 802.15.4 receiver Jan 29 01:34:07 mawk is here! Jan 29 01:34:07 hey...it don't matter. You can always save off a few configs and reimage Jan 29 01:34:18 some neighbor has a connected thingie it seems Jan 29 01:34:18 playplayplay! Jan 29 01:34:49 Snert_: I do not want to make it work. Jan 29 01:34:54 It seems to powerful to me. Jan 29 01:35:39 I got an entire book dedicated to it and realized that .ini files are too powerful to me. Jan 29 01:35:40 ... Jan 29 01:36:04 it's beer:30 so I be off to the store. Ciao! Enjoy the bbb it's a fun world :) Jan 29 01:36:10 Later! Jan 29 01:36:16 BBB! Jan 29 02:16:07 mawk: "caution: networking may lead to communication" Jan 29 02:16:35 yeah Jan 29 02:16:43 the frames is unencrypted, it's a plain broadcast Jan 29 02:16:46 with a 1 byte payload, 0x07 Jan 29 02:16:50 maybe it's for a connected lamp Jan 29 02:16:53 it's broadcasted every 2 seconds Jan 29 02:16:53 lol Jan 29 02:18:20 time to send 0x00 with the same headers one second after each 0x07 broadcast? ;) Jan 29 02:18:50 lol Jan 29 02:18:53 yeah I can try that Jan 29 02:19:02 I'll see lights flicker by my neighbor's window Jan 29 02:20:31 Well? Jan 29 02:20:36 What happened? Jan 29 02:20:41 I did not code the TX yet Jan 29 02:20:42 only RX Jan 29 02:20:45 Oh. Jan 29 02:21:17 I stayed out of it. I would just change my password. Jan 29 02:21:33 or encrypt. Jan 29 02:21:43 there's not even a password or anything Jan 29 02:21:48 the frame is litteraly just 0x07 Jan 29 02:22:03 with broadcast source and destination, and CRC Jan 29 02:22:19 and sequence number and frame type and stuff but that's the MAC layer Jan 29 02:22:19 mawk: maybe log the values over time. if it's a lamp, it'll probably become 0x00 during some part of the day Jan 29 02:22:25 yeha Jan 29 02:22:50 I wondered if that was bluetooth LE, but I don't think it's the same modulation Jan 29 02:22:52 or maybe it is Jan 29 02:23:14 and by chance that exact frame is compatible with 802.15.4 so the baseband engine accepts it Jan 29 02:23:25 with a valid crc? Jan 29 02:23:28 yes Jan 29 02:23:32 the CRC is valid Jan 29 02:23:33 yeah, no. Jan 29 02:24:04 yeah BLE has 3 bytes CRC Jan 29 02:24:06 I just saw that Jan 29 02:24:12 it can't work Jan 29 02:24:55 it may be zwave s2 - already encrypted - on their side I mean. Jan 29 02:25:05 yeah Jan 29 02:25:20 but it's a single byte payload Jan 29 02:25:26 and vulnerable to replay attack, if encrypted Jan 29 02:25:28 and the same byte every time Jan 29 02:25:28 because it never changes Jan 29 02:25:35 also the sequence number is very predictable Jan 29 02:25:38 it's only 4 bits Jan 29 02:26:09 sounds to me like whatever it is is actually just not secured at all Jan 29 02:26:21 yeah Jan 29 02:26:42 Sometimes on Win computers, there is a linux machine that shows face as a device. Could this be it? Jan 29 02:27:08 that thing is mDNS, it's over an ethernet or wifi link Jan 29 02:27:17 here it's a very specific protocol, machines can't show up like that without a proper transmitter and antenna Jan 29 02:27:27 Oh. Jan 29 02:27:42 mDNS or avahi or zeroconf or bonjour or whatever it's called by your vendor Jan 29 02:28:30 security would require at least a sequence number big enough that it won't wrap within any practical timeframe, and an authentication tag of several bytes (which will be randomly-looking for every distinct sequence number) Jan 29 02:29:37 so does the packet not indicate a prototol type? what's the frame format look like? Jan 29 02:29:58 the full packet is "03 08 3F FF FF FF FF 07 61 D3" Jan 29 02:30:22 it's: frame control = 0308, broadcast network, broadcast destination, payload = 0x07, CRC Jan 29 02:30:37 I did not look up what the frame control 0308 means, the standard is very long Jan 29 02:30:43 it's not even free Jan 29 02:30:53 that looks more like a probe of some sort? Jan 29 02:31:03 it's $389 Jan 29 02:31:24 yeah, maybe Jan 29 02:31:33 So mawk: You got some WiFi probe snooping in on you? Jan 29 02:31:45 the IEEE 802 standards are all free (except for a few months after a document is released or something like that) Jan 29 02:31:45 it can't be wifi, it's a valid 802.15.4 frame Jan 29 02:31:54 with the proper preamble, frame format, CRC Jan 29 02:31:59 OH. Jan 29 02:32:19 ah Jan 29 02:32:34 maybe free after they've been superseded or while they're drafts zmatt ? Jan 29 02:32:41 no Jan 29 02:32:43 the one that's $389 is the 2018 revision Jan 29 02:32:47 they're not available while drafts Jan 29 02:32:50 but april 2018 Jan 29 02:33:15 maybe it's free after a year after publication? I thought the period was shorter but I'm not sure Jan 29 02:33:47 the free one currently is indeed the 2015 edition, along with a large heap of amendments Jan 29 02:34:00 and a corrigendum from 2018 Jan 29 02:34:32 I don't see a 2018 version Jan 29 02:34:51 ieee site says 802.15.4-2015 is status Active Jan 29 02:35:16 https://ieeexplore.ieee.org/document/8362834 Jan 29 02:35:39 uh Jan 29 02:35:44 that one is called "8802-15-4" Jan 29 02:35:50 is that a typo or a whole new standard Jan 29 02:36:37 brb...this is getting good. I cannot wait to find out what is snooping. Jan 29 02:37:06 mawk: I'm not sure what this is Jan 29 02:37:09 it's probably a probe as zmatt said Jan 29 02:37:29 yeah it has no form of addressing in it whatsoever Jan 29 02:37:35 just a broadcast address Jan 29 02:37:46 here it is https://serveur.io/802.15.4-2018.pdf Jan 29 02:37:59 it looks like a regular 802.15.4 standard revision, with an extra 8 in front Jan 29 02:38:21 maybe it's the 2015 version with the 2018 corrigendum applied? Jan 29 02:38:49 ah, yeah Jan 29 02:38:51 looks like it Jan 29 02:40:33 ahh, it's the iso republication of the ieee standard Jan 29 02:40:42 I think Jan 29 02:42:12 yeah it's just 802.15.4-2015, without the 2018 corrigendum Jan 29 02:42:20 so the stuff you can download for free is better Jan 29 02:42:20 ah ! Jan 29 02:43:43 So, this is some BLE probe attached to your network? Jan 29 02:44:15 mawk: read the last big paragraph of the foreword (third page) of your 8802 document Jan 29 02:44:27 ("ISO/IEC/IEEE 8802‐15‐4 was prepared by...") Jan 29 02:44:32 set_: it has nothing to do with BLE Jan 29 02:44:36 Oh. Jan 29 02:44:37 Okay. Jan 29 02:44:44 So, it is hardwired? Jan 29 02:45:03 ah Jan 29 02:46:00 it's me that is snooping set_ Jan 29 02:46:10 Oh! Jan 29 02:46:12 I'm hearing over some part of a conversation a device is taking part of Jan 29 02:46:18 it's a wireless protocol Jan 29 02:46:18 Hhahahahaahah. Jan 29 02:46:26 and the received power I have is pretty low Jan 29 02:46:31 around the minimum, -90 dBm Jan 29 02:46:36 You just made me cry. Jan 29 02:46:43 lol Jan 29 02:47:31 So, like phone messaging or networking "IoT" stuff? Jan 29 02:47:48 IoT stuff yeah Jan 29 02:47:52 Okay. Jan 29 02:47:54 Got it. Jan 29 02:48:05 Are you stealing their data? Jan 29 02:48:10 Or borrowing it? Jan 29 02:48:49 They are lending it if it is not encryted anyway. Jan 29 02:49:27 mawk: 03 08 is frame type "beacon" though with a reserved bit set Jan 29 02:49:39 maybe zwave then ? Jan 29 02:49:46 at least it's definitely a beacon Jan 29 02:49:50 if it's a proprietary thing they can break the standard Jan 29 02:50:01 no need to be compatible Jan 29 02:50:02 could also be defined by one of the numerous amendments Jan 29 02:50:05 yeah Jan 29 02:50:12 Damn rules. Jan 29 02:51:10 oh they're not actually that many, and they all seem to be for various physical layers Jan 29 02:52:24 set_ what rules are cursed? Jan 29 02:52:30 All. Jan 29 02:52:49 without rules how would you know how to work with your beagle bone black? Jan 29 02:52:56 Every day...rules ruin my life but I abide by them. Jan 29 02:53:07 I am one of the people working w/ it as we speak. Jan 29 02:53:16 Hold on. Jan 29 02:53:40 Now... Jan 29 02:53:59 The rules of the BBB are rules so to say. I get hat. Jan 29 02:54:03 hat = that Jan 29 02:54:30 Use this communication variation to work w/ this module and use this set of rules for programming it. Jan 29 02:54:53 No. I understand to a fine-thin line point. Jan 29 02:55:00 mawk: z-wave seems to be a totally different thing Jan 29 02:55:36 Rules are more like overseeing bodies working to stay in power. Jan 29 02:55:45 Hmm maybe a LoRa crepe I mean cape. Jan 29 02:56:05 set_ rules are to protect you from me and visa versa. :D Jan 29 02:56:19 I thought it ran over 802.15.4 Jan 29 02:56:21 but maybe not Jan 29 02:56:31 GenTooMan: Okay. You win. Rules are around to save the day. Jan 29 02:56:54 visa versa? Jan 29 02:57:33 set_ and "the other way as well" Jan 29 02:57:38 Oh! Jan 29 02:57:41 vice! Jan 29 02:57:43 Right? Jan 29 02:58:06 set_ hmm probably I was trying it phonetically. Jan 29 02:58:53 Okay. GenTooMan: Have you been paying attention to zmatt and mawk's conversation. Jan 29 02:58:55 ? Jan 29 02:59:12 Snoops-a-daisy. Jan 29 02:59:28 I hope they bug me. Jan 29 02:59:44 Big brother type, you know. **** ENDING LOGGING AT Tue Jan 29 02:59:56 2019