**** BEGIN LOGGING AT Sat Oct 19 02:59:57 2019 Oct 19 04:54:30 18:37 <@zmatt> note for example the BeagleBone-AI is listed as one of the four hardware platforms here: http://www.ti.com/tool/SITARA-MACHINE-LEARNING ... and the other three boards listed are $960, $600, and $900 Oct 19 04:54:30 goddam fucking fucking fuck fuck fuck.... why do companies like this have this knack of making machine learning boring and irrelevant? Oct 19 04:54:47 ? Oct 19 07:47:18 zmatt: heheh you been taken by clever photography Oct 19 07:47:41 1 - The antenna is apparently just that length of micro coax. there is nothing folded (I am looking at the actual unit) Oct 19 07:48:28 2 - The console connector pretty much prevents a nut or any reasonable thickness stand off from fitting. Look how close it is to the copper. Stock bone's don't have that 1mm (?) console connector Oct 19 07:49:09 the Bone's holes are tight so the connector is sure to interfere Oct 19 07:50:26 having said that, a stack with a regular BBB plus a BBAI could be an interesting combo - borrow 5V from the BB-AI so a single USB-C connector can power it. loop the 2 ethernets together for interboard comms and leverage the Wireless on the AI Oct 19 07:51:00 giving a total of 3 PRUs and a somewhat saner pinmuxing from the AM33x for IO Oct 19 07:51:20 all smaller footprint then a X15 Oct 19 12:30:10 ds2: wait what, can you make a photo where the antenna is better visible? Oct 19 12:38:01 and yeah okay now that I look at it again, the console header really is quite close fo it... Oct 19 16:54:39 I have ubuntu 16.04 in bbb wireless in local. I want to backup the image of the ubuntu to windows pc. I need a guide on commands. Is there any way to do that? Oct 19 16:56:31 the debian image has a convenient script for making a backup of eMMC to SD card, no idea about some random other image Oct 19 16:58:53 Thankyou for reply. Bro I think it should support ubuntu too. Can you share me the script? Oct 19 17:00:40 dunno it's somewhere in /opt/scripts I think Oct 19 17:03:46 maybe they're on your ubuntu image as well, I have no experience with unofficial images (such as the ubuntu images) on the BBB Oct 19 17:12:14 another generic solution would be to boot from an SD card with plenty of free space and then make an image of eMMC, e.g. sudo cat /dev/mmcblk1 >backup.img && sync (you may want to use 'pv' instead of 'cat' to get some progress info, but you'd need to install it first, also it'll still hang for a while at the end due to write buffering) Oct 19 19:51:07 is this a good channel to discuss Bela?! or are there more focused or specialised places for Bela? Oct 19 19:56:56 bela? Oct 19 19:57:26 I don't know if anyone here uses bela, I've never seen it discussed here (and I'm here quite a lot) Oct 19 19:58:00 a better place would be their forum => https://forum.bela.io/ Oct 19 20:58:15 @zmatt Do i need same size of sdcard to backup as eMMC? Oct 19 21:01:02 depending on how you backup exactly it should be either 1. at least as big as eMMC, or 2. at least as big as the amount of space used on eMMC (with some margin to spare), or 3. (when booting from SD card and imaging eMMC from there) it should have at least as much free space as the size of eMMC Oct 19 21:02:41 I think nowadays even the cheapest SD cards in stores are way bigger than eMMC, so I can't imagine this being a concern really Oct 19 21:03:22 any SD card that's 8GB or more is definitely fine regardless of the backup method used Oct 19 21:12:36 thankyou Oct 19 21:13:27 apt-get update stucks at 0% [Connecting to ports.ubuntu.com (172.1.8.1)] [Connecting to repos.rcn-ee.com . Do you have any idea? Oct 19 21:15:41 well those sites are working, so my guess would be your bbb doesn't have working internet access Oct 19 21:16:25 although if apt-get gets stuck on those steps (rather than failing immediately) then it seems like your bbb does *think* it has internet access, it's just not actually working :P Oct 19 21:16:54 but ping 8.8.8.8 working Oct 19 21:17:34 that is interesting Oct 19 21:17:46 ping google.com also working. I dont know why Oct 19 21:18:13 try wget http://ports.ubuntu.com/ Oct 19 21:19:47 stuck on this Resolving ports.ubuntu.com (ports.ubuntu.com)... 172.1.8.1 Oct 19 21:20:35 can you share the full output please? (via pastebin.com or similar paste service) Oct 19 21:21:15 since that doesn't sound like it's stuck, since it includes the result of resolving Oct 19 21:23:29 actually that is the full output https://pastebin.com/HMfAEAih Oct 19 21:24:06 no, you didn't include the "Connecting to..." part Oct 19 21:24:19 or if you did, it didn't get through (don't try to paste multi-line text into chat) Oct 19 21:25:10 sorry. i attached pastebin link Oct 19 21:26:10 is netcat ("nc") installed? could you try this: nc -vN ports.ubuntu.com 80 or better: try: wget --no-proxy http://ports.ubuntu.com/ Oct 19 21:28:04 since my guesses right now are either: 1. you have a HTTP proxy configured (that's not actually working), or 2. there's a firewall blocking your outgoing HTTP connections Oct 19 21:32:45 this is the ouputs https://pastebin.com/hYEKv6M3 Oct 19 21:33:13 okay, so it's not a proxy setting, then it's a firewall Oct 19 21:34:04 a really bizarrely configured firewall more specifically Oct 19 21:35:14 The internet shared with win7 using USB. Oct 19 21:36:45 so maybe windows firewall Oct 19 21:37:01 or some other problem with internet sharing Oct 19 21:37:42 dns works because your PC is just proxying it, not sure why pings would work, but it doesn't look like anything else work Oct 19 21:37:45 s Oct 19 21:39:52 I should try to connect internet another way Oct 19 21:40:19 if you have the option to connect ethernet instead of trying to use usb-networking I'd certainly recommend that Oct 19 21:41:50 My BBB doesnt have ethernet. It has wifi. It acts as a wifi server. Is there anyway to change wifi as client Oct 19 21:42:15 it normally does both at the same time Oct 19 21:42:26 you should just be able to connect it to a wifi network Oct 19 21:42:50 (how would depend on what network manager you're using) Oct 19 21:44:04 Actually i am using terminal Oct 19 21:44:29 is there any command to connect bbb to public wifi? Oct 19 21:46:03 I already knew you were using a terminal (presumably an ssh connection more specifically)... how else would you have been copy-pasting the output of terminal commands? :P Oct 19 21:46:13 that doesn't affect what i said Oct 19 21:46:34 how would depend on what network manager you're using Oct 19 21:56:48 ha ha yes. i am suing connmanctl Oct 19 21:56:52 using Oct 19 21:58:05 okay, I don't use it myself but it's also the default network manager on debian, so presumably you can find instructions on the internet for this Oct 19 21:59:11 jkridner[m]: how to connect a wifi-enabled beaglebone to your wifi network is something that should really be in the getting-started guide... especially since for ethernet-equipped beaglebone it's a simple matter of plugging in Oct 19 22:00:00 ^ Oct 19 22:10:37 thank you. Wifi internet is working charm. The problem has to do with the usb sharing. Oct 19 22:10:59 most likely with windows yes Oct 19 22:13:44 Hey! Oct 19 22:13:44 WiFi! Oct 19 22:17:17 I know about connmanctl, sort of. Oct 19 22:20:33 https://pastebin.com/EWuumikA is some source from the xbee-python library online. I found it online after someone told me about it. Oct 19 22:20:34 .. Oct 19 22:21:20 I cannot change the outcome of the LED w/ a button yet but I am trying. Oct 19 22:21:39 Do you see the issue? I have one of my Xbee devices plugged into the BBB via usb. Oct 19 22:22:45 Should I have to use two BBBs or should the one BBB and desktop be okay? Is anyone familiar w/ xbee around here and working w/ the BBB? Oct 19 22:23:55 https://github.com/digidotcom/xbee-python/tree/master/examples/io/RemoteDIOSample is the site w/ instructions, source, and ideas. Oct 19 22:24:00 Anyway... Oct 19 22:25:49 I think this IOLINE_IN and IOLINE_OUT needs to have different statements configured. Oct 19 22:26:16 I do not know where to begin to find these other "statements" for IOLINE_IN and IOLINE_OUT. Oct 19 22:39:26 ... Oct 19 22:40:39 I guess I am asking how is it that the /dev/ttyUSB0 interface connects and sends communication to the DIO4_AD4 IOLINE_IN on my Grove Development Board for Xbees S1? Oct 19 22:41:08 I guess that is about as much sense as I can make right now out of my config. Oct 19 22:49:55 I get no errors but nothing is going on w/ the LED. For instance, I can turn it on/off w/ the XCTU software but not w/ python3 thus far. Oct 19 22:51:06 set_: how is the Bee?! I just learned about it and am VERY curious... Oct 19 22:53:22 Nice. Oct 19 22:53:45 Thus far, I can read samples and almost get the button to change the state of my LED. Oct 19 22:59:04 set_: IOLINE_IN/OUT are just two constants used in the example to pick which of the xbee's IOs you want to read/write Oct 19 22:59:41 Right but what are the statements that go along w/ those constants? I have two configured so far but they are not working. Oct 19 23:00:10 for instance... Oct 19 23:00:21 I don't understand the question Oct 19 23:01:05 IOLINE_IN = IOLINE.DIO2_AD2? Oct 19 23:01:45 what about it? Oct 19 23:02:15 I have my button attached to a Grove Development Board via the grove connector but what should that statement really be called? Oct 19 23:02:29 This one ---> IOLINE.DIO2_AD2? Oct 19 23:02:58 which grove connector? Oct 19 23:03:04 Should I use /dev/ttyGS0 instead of /dev/ttyUSB0? Oct 19 23:03:05 Oh. Oct 19 23:03:08 no Oct 19 23:03:11 Okay. Oct 19 23:03:26 The grove connector for a button and for a LED. Oct 19 23:03:57 I have the grove development board that came w/ the Wireless Connectivity Kit when I got these xbee S1s. Oct 19 23:04:07 If that makes sense. Oct 19 23:04:26 that's the THT one right, not the SMT one? Oct 19 23:04:39 Let me check again. Please hold. Oct 19 23:05:27 see images on page 7: https://www.digi.com/resources/documentation/digidocs/pdfs/90001457-13.pdf Oct 19 23:06:21 okay this is confusing, I found what should have been the schematic of this thing, except it clearly doesn't match Oct 19 23:06:53 oh never mind, I'm just blind Oct 19 23:08:00 THT Oct 19 23:08:07 yeah I assumed as much Oct 19 23:08:15 I am glad you found that site. My computer was going goofy w/ no resources. Oct 19 23:08:23 Back in it. Sorry. Oct 19 23:09:30 I see what happened. Oct 19 23:09:54 It is DIO12_AD12 instead of DIO2_AD2. I could not see the 1 on my development board. Oct 19 23:10:03 so, DIO4_AD4 is used for the "user led/button" on the grove board Oct 19 23:10:03 Let me test it real quickly. Oct 19 23:10:20 I can use it for that, yes. Oct 19 23:10:24 and also one of the grove connectors Oct 19 23:10:44 AD3 is the potentiometer Oct 19 23:11:14 I am using two boards along w/ the two S1s and a BBB w/ one of the boards attached w/ the grove connection of the LED. Oct 19 23:11:48 okay, so? Oct 19 23:12:08 It was not 12. I guess I need to use 4 & 4? Oct 19 23:12:19 DIO4_AD4? Oct 19 23:12:24 for both. Oct 19 23:14:41 I mean, you need to use DIO12 if you want to use "Grove DIO12", or DIO4_AD4 if you want to use "Grove DIO4", the User LED, or the User Button (those all connect to the same pin) Oct 19 23:15:18 Oh. Oct 19 23:16:10 So... Oct 19 23:17:12 It should be GROVE_DIO4 instead of the original DIO4_AD4, right? Oct 19 23:18:50 Hold up. Let me try something. Oct 19 23:24:42 See, I am receiving errors when not using IOLINE_IN/OUT = IOLINE.DIO4_AD4 or IOLINE.DIO2_AD2. Oct 19 23:24:54 IOLINE.DIO12_AS12 does not work for some reason. Oct 19 23:25:02 AS12 = AD12 Oct 19 23:25:31 https://pastebin.com/BXnqCsET Oct 19 23:26:10 because that's an invalid name Oct 19 23:26:26 Oh. Oct 19 23:26:32 https://xbplib.readthedocs.io/en/latest/api/digi.xbee.io.html here's the list of pin names defined by the python library Oct 19 23:26:38 Dang it. Oct 19 23:26:39 Okay. Oct 19 23:27:43 @zmatt: How would I know which pin name I am supposed to use for my THT Board? Oct 19 23:28:05 I have only so many grove connectors and they are all listed w/ specific names. Oct 19 23:28:23 exactly, they're listed with specific names Oct 19 23:28:34 so it should be pretty clear which name to use Oct 19 23:28:52 Okay. Let me try again. Please hold if you are severely board. Oct 19 23:28:53 and like I said, DIO4_AD4 is also the User LED and User Button Oct 19 23:28:57 board = bored Oct 19 23:28:58 sorry. Oct 19 23:29:02 Right. Oct 19 23:29:05 I got it now. Oct 19 23:29:06 (in addition to one of the grove connectors) Oct 19 23:33:10 I get the impression the S1 only has DIO1-8, so maybe avoid DIO12 Oct 19 23:33:18 not 100% sure though Oct 19 23:35:04 Okay. Oct 19 23:35:19 I think it may be the DIO4_AD4 I should not use too. Oct 19 23:35:21 Who knows? Oct 19 23:35:37 I might need to use actual wires and resistors for the set up. Oct 19 23:38:23 you can use DIO4_AD4 as long as you keep in mind it's also used for the User LED and User Button Oct 19 23:38:48 so if you connect a led to it, you'll control both your grove led and the User LED at the same time Oct 19 23:38:51 Oh. Okay. Oct 19 23:38:58 I will switch back to that idea. Oct 19 23:39:03 Off to test it. Oct 19 23:40:42 I only have, like you typed, so many DIO lines I can use, e.g. DIO4_AD4, DIO12 (does not work), and DIO1 but this is i2c. Oct 19 23:40:46 I will check it out too. Oct 19 23:40:56 Some are PWM or ADC. Oct 19 23:41:07 it supports I2C but you can use it for gpio too Oct 19 23:44:23 The print out is working but the LED is not turning off. Oct 19 23:44:26 It is on. Oct 19 23:45:44 @zmatt: No issue. Oct 19 23:45:57 Do not fret. I will attempt this anther day (as usual). Oct 19 23:50:17 I'll let Zmatt worry about fretting. Oct 19 23:51:23 set_: then presumably DIO4_AD4 has not been set correctly Oct 19 23:52:08 note btw that it's active-low, i.e. the led will be on when DIO4 is driven low Oct 19 23:52:44 (confusingly, every other led on the xbee grove board is active-high) Oct 19 23:53:07 Aw. Oct 19 23:53:36 So, I should have not set it up as high in the XCTU software at first when config. took place. Oct 19 23:54:17 See. They have this thing called "chat." This "chat" makes sure that the xbees can communicate and this is done w/ a serial interface or via XCTU. Oct 19 23:54:37 XCTU is just a AT command GUI. Oct 19 23:55:01 Also. Oct 19 23:55:25 Do you think that the Xbee needs to be plugged directly in via USB or should I use a powered USB hub? Oct 19 23:57:04 I mean the xbee works w/ 3.3v levels but w/ this grove board, it may be different b/c of the chip onboard. Oct 19 23:59:18 as usual I have no idea what you're talking about. nothing in what you've typed the last bunch of lines makes sense to me Oct 19 23:59:42 it probably shouldn't matter how you set it up in xctu since you're overriding that setup using python, or at least trying to Oct 20 00:00:14 for DIO4, "digital output low" should turn the User LED on, the other modes should turn it off Oct 20 00:00:34 i see no reason to use a powered usb hub Oct 20 00:00:51 it shouldn't require much power Oct 20 00:01:01 Okay. Oct 20 00:01:05 No issue. Oct 20 00:01:31 I mean. The board does turn on when plugged in via the BBB's usb port. Oct 20 00:01:43 I know, I know. Oct 20 00:02:09 You and I were right earlier. I need to set the Xbee module to low in XCTU for when I try to set it high. Oct 20 00:04:29 ?? Oct 20 00:13:12 Okay. In the xctu software, I set the LED to low/off. Then, I made sure the xbees could chat w/ each other. Oct 20 00:13:23 Now, time for Python again. Oct 20 00:15:16 So, now is time for me to understand you. Oct 20 00:15:47 The LED just turns on w/ the source (w/ or w/out the button being pushed). You typed earlier that it goes high no matter what. Oct 20 00:15:49 ... Oct 20 00:16:30 My set up needs to make sure the button in the source it low first and then use the button for turning on the LED, right? Oct 20 00:19:59 ?????? Oct 20 00:20:11 ? Oct 20 00:20:12 ?? Oct 20 00:20:14 Heh? Oct 20 00:21:14 I just said the User LED will be turned on when dio4 is low and turned off when dio4 is high.... this is known as "active low" since the led is "active" (i.e. turned on) when the digital output is low Oct 20 00:21:38 Okay but... Oct 20 00:22:01 My button still does nothing. Did you look at the script I listed? Oct 20 00:22:23 If that script is not for buttons, fine. Oct 20 00:22:31 But, I figured it was for buttons and LEDs. Oct 20 00:22:41 I probably missed it Oct 20 00:22:44 I could be completely wrong as you are well aware of... Oct 20 00:22:45 https://pastebin.com/BXnqCsET that one? Oct 20 00:22:46 Please hold. Oct 20 00:22:49 I will get it. Oct 20 00:23:05 pastebin seems to be having a problem Oct 20 00:23:14 On my end too. Oct 20 00:23:20 maybe use some other paste service Oct 20 00:23:25 alright. Oct 20 00:23:41 e.g. hastebin.com or paste.debian.net Oct 20 00:23:56 Alright. Oct 20 00:25:36 https://hastebin.com/etewofaqud.py has nice colors. Oct 20 00:29:01 so does pastebin if you select "python" as language... hastebin just guesses the language (often wrong) Oct 20 00:29:46 Oh. It got python right this time. Oct 20 00:30:37 w/ that source, should I be able to change the IOLINE from LOW to HIGH and back again? Oct 20 00:32:56 this looks like it should make the user led on the local device show the state of the user button on the remote device Oct 20 00:33:03 no wait Oct 20 00:33:16 I thought you used dio4 for both Oct 20 00:33:20 I did. Oct 20 00:33:33 One DIO4 on one board and DIO4 on the other board. Oct 20 00:33:35 oh sorry, wrong tab Oct 20 00:33:40 Ha. Oct 20 00:34:36 ok so this is just their example but with the correct PORT and IOLINE_IN/OUT Oct 20 00:34:50 I really have no clue why they're using a thread, but oh well Oct 20 00:35:33 so what's the observed behaviour? it should be printing the state of IOLINE_IN (i.e. the user button) of the remote device... 5 times per second Oct 20 00:35:51 do the printed values reflect the state of the button on the remote device? Oct 20 00:35:58 No. Oct 20 00:36:15 It is always HIGH or always LOW. It depends on what I type and where. Oct 20 00:36:29 So... Oct 20 00:36:42 The info. prints. Oct 20 00:36:45 This is correct. Oct 20 00:36:57 what do you mean? Oct 20 00:37:01 It prints the IOLINE and IOVALUE but the IOVALUE does not change. Oct 20 00:37:11 No matter what I press or where. Oct 20 00:37:12 "It depends on what I type and where" Oct 20 00:37:18 Well. Oct 20 00:37:28 I change the source many times, over and over again for testing. Oct 20 00:37:49 I have not kept track but things are back to the regular state of the source. Oct 20 00:38:15 This was the original issue. It worked but nothing would happen. Oct 20 00:38:16 Now, Oct 20 00:38:35 Do I need to have my LED on the local machine or the remote machine? Oct 20 00:38:42 could you add this after local_device.open(): print("local device:", local_device.get_node_id()) Oct 20 00:39:06 don't attach any grove module for now Oct 20 00:39:22 Okay. Oct 20 00:39:29 first just test with the user button and user led on the xbee grove board itself Oct 20 00:39:38 I got that part to work. Oct 20 00:39:56 Wait... Oct 20 00:41:18 local device: Xbee_A Oct 20 00:41:43 I have a Xbee_A and Xbee_B Oct 20 00:41:49 if you're going to try a grove module, I recommend using the Grove AD2 (pin DIO2_AD2) since that pin isn't used for anything else Oct 20 00:42:09 Where on my grove module is that located? Oct 20 00:42:12 uhh then your script can't possibly work, it should fail with "Could not find the remote device" Oct 20 00:42:26 since your script is looking for a device named "REMOTE", not "Xbee_B" Oct 20 00:42:32 I changed that idea. Oct 20 00:42:48 I changed "Remote" to Xbee_B. Oct 20 00:43:02 Xbee_B has the LED on it. Oct 20 00:43:13 Grove AD2 is located on your board next to the label that syad "Grove AD2" Oct 20 00:43:16 *says Oct 20 00:43:29 that also doesn't match your script Oct 20 00:43:29 I found it. So, AD2 is DIO2_AD2. Got it. Oct 20 00:43:41 your script is checking the button on the remote module and setting the led on the local module Oct 20 00:43:45 not other way around Oct 20 00:43:50 Ut oh. Oct 20 00:44:12 Input is the local NODE right? Oct 20 00:44:21 local node is the one connected to the BBB Oct 20 00:44:21 and Output is the remote node? Oct 20 00:44:27 Right. Oct 20 00:44:31 remote node is the node reached via wireless Oct 20 00:44:35 Right. Oct 20 00:44:42 Okay. Oct 20 00:45:01 I will try the DIO2_AD2 pin on my dev. board for the S1 xbee. Oct 20 00:45:04 Please hold. Oct 20 00:45:13 their example script, including the modified version you shared, uses IOLINE_IN on the remote device as input and IOLINE_OUT on the local device as output Oct 20 00:45:40 Oh. Oct 20 00:45:47 Output is on the BBB then. Oct 20 00:45:53 Yikes. Oct 20 00:46:06 Sheesh. Off to make it work now. Oct 20 00:46:09 that should be immediately obvious from looking at the code, e.g. "local_device.set_io_configuration(IOLINE_OUT, IOMode.DIGITAL_OUT_LOW)" and "local_device.set_dio_value(IOLINE_OUT, io_value)" Oct 20 00:46:43 I kept going googlie eyed around that code. Oct 20 00:46:49 Thank you. Oct 20 00:46:58 if you want it the other way around, swap "local" and "remote" in the four relevant lines (the ones that set_io_configuration() and get/set_io_value()) Oct 20 00:47:12 Okay. Oct 20 00:47:59 I don't really understand how this can be a surprise to you, since you just said you tested it with the user button and user led, and you said it worked... Oct 20 00:48:16 so you would have used the button on the remote device and seen the led on the local device there as well Oct 20 00:48:42 I must have gotten the two boards mix-matched and then plugged on into the BBB. Oct 20 00:48:49 Who knows? I fooled myself again. Oct 20 00:49:10 no then the script would have failed Oct 20 00:49:17 swapping the boards would break the script Oct 20 00:49:33 Well. Oct 20 00:50:04 I have done so much swapping w/ this Xbee stuff, I am sure I got it confused to the point that I knew nothing about what happened. Oct 20 00:50:18 That is why I brought it up. Oct 20 00:50:35 I am sorry I cannot figure out exactly what happened. I can take time out if necessary. Oct 20 00:50:51 since it identifies the remote device by node_id while it identifies the local device by the fact it's physically connected to the bbb. hence if you'd attach Xbee_B directly to the BBB, then it would be used both as local_device *and* as remote_device, which will guaranteed not work Oct 20 00:52:02 anyway I don't see why it matters much, it's trivial to change based on what you actually want anyway Oct 20 00:52:09 At first, that was the issue. Oct 20 00:52:19 It would not work. Their error would arise. Oct 20 00:52:34 At first, yes. Oct 20 00:52:47 but we weren't talking about when it didn't work, I was talking about when it did work Oct 20 00:53:00 Then, I started to manipulate the source and the board arrangement. Oct 20 00:53:02 or so you claimed anywa Oct 20 00:53:37 anyway, whatever Oct 20 00:54:02 It worked (I thought it did). It must have not worked. Maybe, when it was the time when I just used the xbee carrier boards, I made things worked and changed boards w/ carrier boards. Oct 20 00:54:05 I cannot remember. Oct 20 00:54:11 You are right. Oct 20 00:54:20 I cannot remember and you figured it out. Oct 20 00:54:26 ... Oct 20 01:00:10 I see why it is so important to test and record things now. Oct 20 01:00:19 W/out recordings, there was no tests. Oct 20 01:28:37 set_ for you own good remember to have a note book handy when you work on things. Oct 20 01:29:31 Actually I mean USE the note book so you remember what you did. Oct 20 02:26:12 I think I missing something.... the BeagleBoard-X15 is insanely expensive for what it is...? What justifies the high price? Oct 20 02:30:23 what makes you think that? can you give an example of a substantially lower-cost board that you think has a comparable or better feature-set? Oct 20 02:31:20 I'll readily admit it's definitely not a board for everyone (and that more limited audience obviously also tends to prevent lowering costs) Oct 20 02:32:20 zmatt: I've been looking through the BBB website and your challenge for me is difficult for me because that info is so hard to find Oct 20 02:32:22 I mean,...... Oct 20 02:32:32 it has ONE of those chips Oct 20 02:32:51 the main one (can't remember its PN) Oct 20 02:33:02 costs 50 GBP from digikey Oct 20 02:33:13 then a whole load of the same old cheap hw Oct 20 02:33:42 my point is this... Oct 20 02:33:58 there is nothing written down anywhere that make this a compelling product Oct 20 02:34:08 the beaglebone AI is probably more interesting for a lot of applications, being cheaper and easier to integrate... as long as the more limited interfaces and reduced amount of expansion I/O is not a problem Oct 20 02:34:17 nothing that makes me go, "ooooh! tis is going to help me do x, y, z" Oct 20 02:34:31 zmatt: you are being as obtuse as the web pages Oct 20 02:34:47 lol Oct 20 02:35:10 I have a PhD in AI, and I can't see anything particular great about the BBB-X15 that warrants the high price Oct 20 02:35:14 I mean, to be fair I haven't been hugely motivated to buy one yet myself... but then I already have a bbx15 Oct 20 02:36:02 here I am... Oct 20 02:36:09 I have a background in AI Oct 20 02:36:12 for one, the bbx15 can be viewed as a low-cost evaluation board for TI's AM57xx family of SoCs (and for that purpose it is indeed low-cost) Oct 20 02:36:23 in fact it is basically the am572x-evm Oct 20 02:36:26 I am literally BEGGING ho to convince me to pay 250 GBP for a BBB-X15 Oct 20 02:36:34 I have NO IDEA why I would... Oct 20 02:36:37 STILL Oct 20 02:37:13 I think the BBB people are using AI as a marketing buzzword Oct 20 02:37:41 if you don't then you probably shouldn't. on the other hand if you'd be an existing beaglebone user thinking "ooh, I could definitely use a second PRUSS along with a bit more power in general" then it's a lot more interesting Oct 20 02:38:13 I AM an existing BBB user Oct 20 02:38:22 hence my question about the Bela earlier Oct 20 02:38:44 sorry I have the memory of a goldfish sometimes, I rarely remember who asked/talking about what Oct 20 02:39:28 so, Bela is an application that actually relies quite heavily on PRU afaik? so if it would want to expand beyond the limitations of the AM335x, then the AM572x would be the logical upgrade path Oct 20 02:40:09 and before the BeagleBone-AI came out, the BeagleBoard-X15 would have been a good candidate Oct 20 02:41:22 they use the same AM572x SoC correct? Oct 20 02:41:32 both use the AM5729 yes Oct 20 02:41:50 GenTooMan: You are right. I need a lesson on notes. Oct 20 02:44:28 ok, let me lower the expectations Oct 20 02:44:39 what are you expecting it to do? Oct 20 02:45:00 zmatt: I'll try to make a picture when I get a chance Oct 20 02:45:05 ullbeking: as for the "AI" stuff, I don't really know much about it. from the bits I've read at TI, my impression is that they're trying to get in the Deep Learning hype train by positioning their SoCs for the purpose of running your neural nets (trained on much beefier hw) in embedded applications Oct 20 02:45:30 can somebody please tell me an "AI" algorithm that this new BBB excels at? Oct 20 02:45:42 zmatt: hmmm Oct 20 02:45:44 ok Oct 20 02:45:53 that's ... an interesting proposition Oct 20 02:46:05 can I build a cluster of BBB's easily? Oct 20 02:46:11 by offering tooling that can compile them to target the various computational cores (C66x DSP and EVEs) their SoCs have Oct 20 02:46:12 are there specs online? Oct 20 02:46:27 for the chassis, etc Oct 20 02:46:41 (which were previously mainly targeted at things like automotive vision / advanced driver assistance) Oct 20 02:46:51 most likely inference of CNN... will know more once I get things setup Oct 20 02:46:54 and why is the BBB good for AI over, say, the OPi? Oct 20 02:47:05 oh CNN's, the new hotness Oct 20 02:47:07 what's the OPi? Oct 20 02:47:10 Orange Pi Oct 20 02:47:20 what's on that irational thing? Oct 20 02:47:27 (it's my favourite SBC) Oct 20 02:47:38 (and it's cheap so I can build a big cluster) Oct 20 02:48:00 it is unlikely the BBAI can do training reasonably well Oct 20 02:48:05 you'd need to benchmark it, but I think the two C66x DSPs and four EVEs that are on the AM572x might add up to a fair bit of computational power, if they can be used effectively for this application Oct 20 02:48:18 no they're not even suggesting training on these processors Oct 20 02:48:27 just inference Oct 20 02:49:16 ... Oct 20 02:49:27 jason made a video showing the bbai with a cam doing object recognition using a pre-trained neutral net (if I understood correctly what was going on) Oct 20 02:49:28 I got that darn LED lit up by command finally w/ the Xbees. Oct 20 02:49:42 set_: Taking notes is not hard but requires discipline that's all. that aside. Oct 20 02:49:53 Yea, yea, yea. It works! Oct 20 02:50:08 like I said, I'd genuinely love to be convinced Oct 20 02:50:13 it is a lot of power but doing image stuff can outpace that with all the C's it needs t do Oct 20 02:50:13 Now, I can control motors and other things. Oct 20 02:50:18 ullbeking: https://training.ti.com/sites/default/files/docs/am57x_ti_deep_learning_overview.pdf Oct 20 02:50:23 but I'm finding it difficult to find the good stuff in among the web pages Oct 20 02:50:29 ty zmatt Oct 20 02:50:32 yeah I can imagine Oct 20 02:50:38 the DSPs have limited execution paths Oct 20 02:50:45 the EVE is likely to have a bigger punch Oct 20 02:50:48 ds2: dsl is my thing, really Oct 20 02:50:54 dsp* Oct 20 02:50:58 music and audio Oct 20 02:51:01 I like the C66x Oct 20 02:51:11 ullbeking: yes but in the context of a CNN? Oct 20 02:51:24 ds2: duo can do chintzy recognition tasks Oct 20 02:51:27 you ca* Oct 20 02:51:32 you can* Oct 20 02:51:46 for each image, you got a crap load of C's to do that feeds into a NN which goes into stuff like RELU then prehaps more C's Oct 20 02:52:19 i'd think the SGX can do the C's faster with the shaders but that's not used Oct 20 02:54:32 the issue with audio is this... Oct 20 02:54:46 TI's slides say each EVE can do 16x 16-bit MAC per cycle, hence 10.4 GMAC/s (16-bit integer) per EVE at 650 MHz Oct 20 02:54:54 can the convulsion in CNN's model natural reverberation? Oct 20 02:54:54 and there are four EVEs Oct 20 02:56:01 and apparently each EVE consumes only 0.11 W of power under full load Oct 20 02:56:12 betterthen dsp Oct 20 02:56:37 "TIDL runs 1.5x-4x faster on EVE subsystems" (compared to C66x) Oct 20 02:57:36 ullbeking: if you want some concrete info rather than marketing blah, http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_TIDL.html Oct 20 02:57:52 ty again zmatt Oct 20 02:57:53 :D Oct 20 02:58:05 it was I think the first or second google search result ;) Oct 20 02:58:51 this is great because I've been wanting to learn mcu programming with ti dev boards for a long time Oct 20 02:58:52 interesting that TI barely seems to acknowledge the existence of the AM5729 (2xC66x + 4xEVE) Oct 20 02:59:13 I wonder if my expectations are on point **** ENDING LOGGING AT Sun Oct 20 02:59:58 2019