**** BEGIN LOGGING AT Tue Oct 06 02:59:56 2020 Oct 06 03:00:13 everything about this is horrifying Oct 06 03:00:13 I cannot save my coordinates to file w/ that tech. and input them into a file for viewing my movements at a later time! Oct 06 03:00:36 that would probably be at most 10 lines of code Oct 06 03:01:00 So, w/ that file, I can input it into a .kml file and place it in GOogle Earth w/ my saved coordinates and movements. Oct 06 03:01:42 Later, I can see exactly where I went, left or right, and i can tell w/ a nice shade of burgandy. Oct 06 03:01:43 Ha. Oct 06 03:02:13 https://gpsd.gitlab.io/gpsd/index.html Oct 06 03:02:18 w/ gpsd, I cannot figure out how to just save the coordinates over and over until they are stopped by me. Oct 06 03:02:20 I know. Oct 06 03:02:36 gpsd does not work for me w/ this Grove_GPS. Oct 06 03:02:40 set_: how to save the coordinates is not related in any way to how you obtain the coordinates Oct 06 03:03:07 Right. But the coordinates in a particular encoding is! Oct 06 03:03:30 I need to have them in 76.44564 x 89.112243. Oct 06 03:03:30 just make sure the pins are muxed correctly at boot by enabling the correct overlay for the uart, and configure the uart path in the DEVICES variable in /etc/default/gpsd Oct 06 03:03:38 okay, and? Oct 06 03:03:57 I need to save those coordinates and plug them in to Google Earth Later. Oct 06 03:03:59 like, unlike what? Oct 06 03:04:04 yes, and? Oct 06 03:04:12 like, why would that be a problem? Oct 06 03:04:21 gpsd can do that...yes. I cannot get it to work any longer. Oct 06 03:04:48 30 files and boom, 4.0! Oct 06 03:04:58 gpsd does not care what you do with the data, printing it to file is completely up to you, in all cases Oct 06 03:05:11 (and also the same in all cases) Oct 06 03:05:12 Oh okay! Oct 06 03:05:29 (and preferably done in a less horrible way than this script does) Oct 06 03:05:31 So, /etc/default/gpsd. Oct 06 03:05:53 actually, I... don't really want to spend any time on this Oct 06 03:06:02 afk Oct 06 03:07:59 http://redhog.github.io/agpsd/ Oct 06 03:08:23 I looked. Yea! Oct 06 03:08:47 I set up "/dev/ttyS2" to gpsd options. Oct 06 03:08:58 Now, I started the daemon. Oct 06 03:09:04 Now, what should I do? Oct 06 03:09:05 Ha. Oct 06 03:09:09 he left Oct 06 03:09:11 Oh. Oct 06 03:09:13 Dang. Oct 06 03:09:15 Oh well. Oct 06 03:09:22 I am good at angering that fellow. Oct 06 03:09:40 look at the last lik i pasteed Oct 06 03:09:43 link Oct 06 03:09:48 it uses gpsd Oct 06 03:09:59 and output kml Oct 06 03:10:12 I will just do something and get it right finally. Oct 06 03:10:17 In time! Oct 06 03:12:54 In time! Oct 06 03:12:59 In time! Oct 06 03:13:00 Ha. Oct 06 03:25:34 I suggest after 10pm set_ you do a nice nap :D Oct 06 03:25:50 Fine. GenTooMan! Oct 06 03:32:17 Night, Night, GenTooMan, Night, Night? Oct 06 03:53:59 Fine! Oct 06 03:56:58 Every thing used to be fine and dandy, i.e. you guys changed. I am moving to FL. Oct 06 04:21:13 Oh! Oct 06 04:21:20 Arm Dev. Summit tomorrow. Oct 06 05:27:46 Does the BB Blue have same pin mux as BB Black? Oct 06 05:57:15 Hello, I want to talk to you about cooperation, can you? Oct 06 06:01:46 ? **** BEGIN LOGGING AT Tue Oct 06 06:44:39 2020 Oct 06 07:37:42 vedant16[m]: no, the bbblue has completely different connectors Oct 06 07:38:25 vedant16[m]: unless you mean whether pinmux works in the same way (i.e. using config-pin or alternatively using overlays), then yes it does Oct 06 07:42:51 Yeah, I mean this. Oct 06 07:42:55 not the physical connector Oct 06 07:44:00 So, same overlay for bb black will seamlessly work on bb blue? Oct 06 07:46:04 no? Oct 06 07:46:11 what overlay? Oct 06 07:46:42 the hardware is completely different so it is unlikely for an overlay written for the beaglebone black to make any sense on the beaglebone blue Oct 06 07:48:00 in case it's of any use, I've made an overview of pins on the beaglebone blue: https://pastebin.com/hBiyzGWL (this shows all pins available on external connectors as well as a few others that might be useful such as leds) Oct 06 07:51:00 a much more detailed table of all pins and mux modes available for each pin can be found in the BBBlue tab of my pins spreadsheet: https://docs.google.com/spreadsheets/d/1CK5c-Cs8G1RtzGo-J3VJsD9m5K-fp06AncgeYWsdjSU/view#gid=1569752740 Oct 06 08:00:47 short url: https://goo.gl/Jkcg0w#gid=1569752740 **** BEGIN LOGGING AT Tue Oct 06 08:02:57 2020 Oct 06 08:47:30 zmatt Thanks a lot for this. Oct 06 08:47:43 even GitHub wiki of bb blue is blank **** BEGIN LOGGING AT Tue Oct 06 09:11:09 2020 **** BEGIN LOGGING AT Tue Oct 06 09:14:58 2020 **** BEGIN LOGGING AT Tue Oct 06 09:49:03 2020 **** BEGIN LOGGING AT Tue Oct 06 12:31:39 2020 Oct 06 12:51:55 It appears I have to figure out how to rsync to another system; my development unit will no longer create flasher SDs. I'll probably wind up going on-site and getting another, but if using this 'opportunity' to go direct to disk works out, I'm game. Oct 06 13:11:00 Hello, I am using a Beaglebone black wireless to send audio over WiFi on Multicast, and I am getting an average of 50% of packets lost. I used IPERF to check the channel in 2 modes. First as multicast, I get a low bitrate around 400kbps, and packets lost sometimes reach out to 80%. But when I try IPERF on unicast mode, packets lost are less than Oct 06 13:11:01 1%. I am using lastest debian distribution on beaglebone.org. **** BEGIN LOGGING AT Tue Oct 06 14:50:40 2020 **** BEGIN LOGGING AT Tue Oct 06 15:17:37 2020 Oct 06 15:34:35 Can anyone recommend a good AM3358 SoC compute module board? I'm trying to compare the Rpi CM3+ with BBB-style compute modules for performance/price comparison? Oct 06 15:35:18 I think your only option is the pocketbeagle Oct 06 15:35:25 but don't quote me on that Oct 06 15:38:36 MYIR tech might be worth a look too Oct 06 15:39:24 scm1hewf: Thanks for the quick reponse, but the pocketbeagle is a small USB dev kit, but not an integratable compute module. I guess my broader question is are there other production level (not dev kits) SoC compute modules that can compete against the Rpi CM3+ for price and performance? It seems to pack a lot of computing muscle in for only ~$30; are there others that can match or beat it? Oct 06 15:40:15 gotcha... I have no experience of the MYIR tech stuff or the Compulab CM, but they both appear to offer what you want Oct 06 15:40:22 sodimm sized module Oct 06 15:41:49 am3358 is a better SOC imho - but I use the PRU extensively and the broadcom BCM on the RPi doesn't have that Oct 06 15:42:03 scm1hewf: thanks, I'll check those out! **** BEGIN LOGGING AT Tue Oct 06 15:59:16 2020 **** BEGIN LOGGING AT Tue Oct 06 17:03:53 2020 **** BEGIN LOGGING AT Tue Oct 06 17:41:42 2020 **** BEGIN LOGGING AT Tue Oct 06 17:45:35 2020 **** BEGIN LOGGING AT Tue Oct 06 17:55:35 2020 **** BEGIN LOGGING AT Tue Oct 06 18:19:48 2020 Oct 06 18:30:42 brianjaod: there are a bunch of am335x-based SoMs on the market... though the am335x is rarely used for its "performance" (which, being a 1 GHz cortex-a8 is not impressive), it's its I/O capabilities and PRU, along with the fact that the SoC is very well documented and can actually be purchased in low quantity by anyone Oct 06 18:31:43 brianjaod: unlike the broadcom SoC which doesn't even have a product page acknowledging its existence last time I checked, and the "documentation" is a very short doc cobbled together by someone from the rp[ foundation rather than being official broadcom documentation of the SoC **** BEGIN LOGGING AT Tue Oct 06 18:36:27 2020 Oct 06 18:38:04 TI and NXP are really the only sane choices for performance SoCs Oct 06 18:38:25 ST and microchip are ok at the lower end Oct 06 18:39:41 I'm sure broadcom makes sense for specific use cases.. like, low cost very high volume use cases Oct 06 18:40:08 and undocumented Oct 06 18:41:22 I'm sure broadcom is more helpful when you're a real customer Oct 06 18:45:47 sure, if you're buying by the million Oct 06 18:46:06 like I said, very high volume use cases **** BEGIN LOGGING AT Tue Oct 06 19:05:57 2020 Oct 06 19:09:36 Millions === real customer, clearly. Oct 06 19:10:56 yeah they're not gonna care if you're some schmuck who only needs a few tens of thousands **** BEGIN LOGGING AT Tue Oct 06 19:28:05 2020 **** BEGIN LOGGING AT Tue Oct 06 19:54:21 2020 **** BEGIN LOGGING AT Tue Oct 06 19:59:16 2020 Oct 06 20:29:10 I've got another question about device trees. I want to setup the SPI bus on the BeagleBone AI, and this is currently my device tree https://pastebin.com/AqNhba4Q Oct 06 20:29:57 My question is, do I need to set the mode of the SPI pins in the mcspi3_pins node, or the cape_pins_default node? **** BEGIN LOGGING AT Tue Oct 06 21:03:57 2020 Oct 06 21:07:27 I'm having trouble articulating my question, but I guess what I'm wondering if I setup a pin (like P9.17) as the SPI CS in the mcspi3_pins node and then set that same pin up as a GPIO in the cape_pins_default node? Which takes precedent?