**** BEGIN LOGGING AT Fri Nov 08 02:59:57 2019 Nov 08 03:04:41 so you would be paranoid but he was out to get you? Nov 08 03:07:09 I think I was disturbing the room by sitting where I sat b/c of the desk being faulty. Nov 08 03:22:25 set_ sometimes your the bug and sometimes your the windshield huh? well irritating the prof is probably not the best idea. Nov 08 03:30:49 Right-O! Forget statistics. Hello failure! Nov 08 05:14:47 ewwwwwwww wrapping everything in python...yuck Nov 08 13:27:41 ds2: you're more a fan of wrapping everything in java? :) Nov 08 14:40:06 zmatt java the funny thing about Java as a language is the JVM is more commonly used by other languages. Like Jython Jruby et al. Nov 08 15:10:59 I just killed a beagle bone black with no real explanation. I unplugged it, and when I plugged it back up it was dead. Now that I've killed a BBB and a BBAI I'm hoping they will start to fear me.... Nov 08 15:11:47 hunter2018[m]: define "dead"... the power led doesn't turn on? did the beaglebone have any external hardware connected via expansion headers? Nov 08 15:13:07 Yeah, no lights turn on at all. So I did have external hardware connected, but I don't think it was the cape. I moved it to another BBB after the first died and it seems to be working fine. Nov 08 15:14:03 do you get at least get the 1 quick led "blip", when you insert power? Nov 08 15:14:06 but it is possible a cape inflicts injury on the BBB during power cycles Nov 08 15:14:11 * do you at least get the 1 quick led "blip", when you insert power? Nov 08 15:14:22 I presume you've tried flashing just for feces and grins? I thought I'd bricked an AI, but flash worked. Nov 08 15:14:27 No, no blip at all. We've only tried it with USB. Nov 08 15:14:39 Ragnorok: if the power led doesn't turn on that's kinda a step you can skip :P Nov 08 15:15:43 hunter2018[m]: and I still win... https://photos.app.goo.gl/y4dePpZtsZhee1L3A ;) Nov 08 15:16:12 ;) Nov 08 15:16:43 zmatt: (shrug) Stranger things have borne fruit. You may have more dead Blacks than we do. That's impressive. Nov 08 15:17:22 this doesn't include beaglebones whose eMMC died, which we donate to a hackerspace Nov 08 15:18:08 and I still have a bunch that need to be tested/examined Nov 08 15:18:11 Nice! But at the rate I'm going I'll be caught up to you in 6 months :) That's my goal, more dead beagle bones than zmatt. Nov 08 15:18:24 lol It's good to have goals. Nov 08 15:19:08 lol Nov 08 15:19:50 It's like they say "you've got to crack a few eggs to make an omelette" Nov 08 15:20:22 Sadly we can't use the AI as a Black upgrade. On our board, in our box, at idle with the IoT firmware and the EVE/DSP disabled, it overheats in 37 minutes. (pout) I was really looking forward to put that guy on there. Nov 08 15:21:18 Ragnorok: just fill the box with a non-conductive liquid coolant and install a small circulating pump ;) Nov 08 15:21:51 (nods head) Waterproof the board ... the could work! Nov 08 15:22:11 the box you mean Nov 08 15:22:23 Well everything, Just To Be Sure. Nov 08 15:23:08 "See this little box? That's our product. See this big heat sink? That's needed to make it go!" Nov 08 15:23:23 not sure you'd actually need a big heat sink Nov 08 15:23:40 Come now. It's a funny! You're ruining it. Nov 08 15:23:46 just conducting the head away from the AI to a box with a larger surface area would already help a lot Nov 08 15:24:09 *heat Nov 08 15:24:34 but you will need a water-tight box to keep the fluorinert from leaking out ;) Nov 08 15:24:36 Our plan is to make sure the AI is always mounted on a quadcopter so that the rotor down wash keeps it cool :) Nov 08 15:27:20 hunter2018[m]: is the cape powered solely by the 3.3V supply from the beaglebone? Nov 08 15:28:17 (power domain crossings are the easiest way to cause damage during power transitions) Nov 08 15:28:33 The cape is actually powered from the 5V rail. Not on the barrel plug side of the 5V rail, but the 5V coming out of the PMIC. Nov 08 15:28:55 I forget if it is called VDD 5V or SYS 5V Nov 08 15:29:38 hunter2018[m]: sys_5v, but that rail still comes up before the 3.3V supply of the beaglebone does, hence you need to be really careful if you derive an independent 3.3V supply from it Nov 08 15:29:48 What is a power domain crossing? Like 5V going through the cape to the 3.3V rail? Nov 08 15:31:35 hunter2018[m]: signals crossing from one power domain to the other, by which I mean a collection of hardware powered from a particular supply. even if both sides use the same nominal voltage (which is typically a hard requirement), that doesn't make them the same power domain if the supplies are independent and are not guaranteed to switch on/off at the same time Nov 08 15:32:54 whenever this happens explicit care needs to be taken to consider what happens during power transitions, to ensure the powered side can't damage the unpowered side Nov 08 15:33:39 Gotcha, so the sys_5V does power a GPS module through a 3.3V regulator on the cape. However, the only tie back to the BBB are UART and a pulse per second signal from the GPS. I wouldn't think these become active soon enough to do any damage. Nov 08 15:34:04 is that a fact or an assumption? an uart signal tends to be high by default Nov 08 15:34:52 driving a BBB pin high to an independent 3.3V supply powered from sys_5v is an easy way to injure the BBB every time you power on Nov 08 15:36:20 If that is the case, how could you prevent this? I guess you could have the power to the GPS module controlled by a BBB pin so that it is only applied after the BBB boots up... Nov 08 15:36:33 Also, would putting inline resistors to these signals work? Nov 08 15:36:43 inline resistor does not suffice Nov 08 15:37:04 (though it may reduce the injury so it'll take longer for the I/O cell to get damaged) Nov 08 15:38:48 We use GPIO pins on our external powered bits. Seemed simplest. It also allows us to power down/cycle subsystems on-the-fly. Nov 08 15:39:15 solutions are: 1. use the 3.3V supply from the beaglebone 2. switch the independent supply based on a GPIO (with external pull-down resistor) or based on the reset output 3. same as (2) but instead of switching the power somehow ensure signals to the BBB are high-impedance or driven low (instead of powering off entirely) Nov 08 15:39:40 benefit of (3) is that it reduces risk of getting power domain violations in the other direction (BBB driving signals into unpowered external hardware) if you get sequencing wrong Nov 08 15:40:27 (1) is generally the easiest provided the 3.3V supply from the beaglebone can supply adequate current for your application Nov 08 15:41:09 hunter2018[m]: I presume you're aware of the powerdown problems if the Black is using it's PMIC for battery charging? Given you also mentioned AI I suspect you're using your own power. Nov 08 15:42:05 No, I'm not familiar. Wait, does the BBB have an on board battery charger? Nov 08 15:42:07 there are also ways to get signals across power domains safely, regardless of whether both sides are powered, e.g. use an open-drain driver (tolerant to a voltage on its output while unpowered) on the driving side and a pull-up to the receipient's supply Nov 08 15:42:22 hunter2018[m]: it does but it's close to useless Nov 08 15:42:49 hunter2018[m]: It does, but if you aren't using it, it would probably be best not to go there. I'm currently redesigning the power section of our board to include its own PMIC. Nov 08 15:43:36 another way to cross power domains is by using a level shifter Nov 08 15:59:32 zmatt: so you're right. The gps has two pins that go high when power is first applied, the uart TX pin and the PPS pin. Here is a scope capture showing the BBB 3.3V rail in yellow on CH1 and the gps module's TX pin on CH2 in blue: https://photos.app.goo.gl/kFtwHmpCLmg19rVTA Nov 08 16:00:09 m Nov 08 16:00:45 The TX line doesn't immediately go the 3.3V though, it starts at about 1.7V till transmission begins. Nov 08 16:02:24 And here is the same thing, but the PPS line instead of the TX line on the GPS. https://photos.app.goo.gl/Pb6JyivUXpKCt64W6 Nov 08 16:03:01 This one starts out at like 2.5V, I'm not sure why they aren't starting out at 3.3V? Nov 08 16:03:51 I guess they aren't being fully driven by the GPS or the BBB is drawing too much current. Nov 08 16:13:51 hunter2018[m]: the BBB is drawing too much current since you're trying to power the entire BBB's 3.3V supply rail via the protection diode of the I/O cell(s) being driven Nov 08 16:14:13 which is something the I/O cell does not enjoy Nov 08 16:14:48 and which may end up damaging the I/O cell in such a way that it turns into a rail-to-rail short-circuit, causing the BBB to fail to power on Nov 08 16:15:34 "That can't be good." - Porko Rosso Nov 08 16:15:42 i'm shocked that i haven't managed to kill a BBB yet Nov 08 16:15:52 with my terrible board hygeine habits Nov 08 16:16:04 hunter2018[m]: although, you're saying this is showing the BBB's 3.3V rather than the gps module's 3.3V ? Nov 08 16:17:53 maybe the lines are actually high-Z on both sides initially? Nov 08 16:18:19 (with inadequate pull-up or conflicting pull-up/down) Nov 08 16:18:50 kremlin: it can survive quite a bit... until it doesn't Nov 08 16:20:08 hehe Nov 08 16:20:33 Yeah, this is the BBB 3.3V on CH1, not the GPS board's 3.3V Nov 08 16:21:59 So I don't think it's the 3.3V supply rail being driven through the diode making the 2.5V and 1.7V on these pins Nov 08 16:22:57 agreed since the worrisome part is the time between sys_5v switching on and vdd_3v3 switching on Nov 08 16:24:18 can you check with sys_5V as trigger instead of the 3.3V ? Nov 08 16:24:22 do you miss any protection circuitry powering directly through the SYS_5V pin ? Nov 08 16:24:44 sys_5v has current-limiting Nov 08 16:25:04 the main issue with using it is that it turns on much earlier than other supplies Nov 08 16:25:59 is it non an intended faeture that people power things through it? Nov 08 16:26:55 Oh yeah, so I'm dumb. The SYS_5V (and hence my GPS 3.3V) comes up a full 55ms before the BBB 3.3V. The fact that my images show the TX and PPS lines coming up at the exact same time as the BBB3.3V must be because before this moment they are being pulled down by the reverse protection diodes. Nov 08 16:27:26 kremlin: not at all, it's the obvious choice to use when you need a 5v supply Nov 08 16:27:43 hmm Nov 08 16:28:47 kremlin: but if you want to drive signals into the BBB you should use the 3.3V supply from the beaglebone, and if you don't then you need to be very careful to avoid violating absolute maximum ratings Nov 08 16:28:58 ic Nov 08 16:30:22 this is true for nearly all digital logic: generally the voltage on inputs may not be significantly below 0V or significantly above the I/O supply (where "significantly" may vary a bit, e.g. 0.3V or 0.5V) Nov 08 16:30:54 (unless you've verified that the component explicitly allows voltages outside this range) Nov 08 16:35:58 Still I don't understand why once the BBB 3.3V comes up the PPS and the TXD lines are still slightly lower than 3.3V. It gives me hope that they are high-Z during this time, which would be a lot better than them driving at full strength through the protection diodes. Nov 08 16:36:17 hunter2018[m]: that would be my guess yes Nov 08 16:37:53 So I'm thinking this isn't actually what killed my BBB. Though, could the current though a high-z pin with a pullup still be enough to hurt the BBB gate while unpowered? Nov 08 16:38:13 Aren't the pull ups usually in the 10k-100k range? Nov 08 16:39:15 you'd need to check your module's datasheet Nov 08 16:39:54 I'm used to 8-bit micros that are pretty resilient and can literally be powered fine through a GPIO pin's doide, but I'm assuming this processor on the BBB is a lot less tolerant of this kind of thing... Nov 08 16:40:07 anyway I agree this seems to be benign since the voltage isn't very high on the I/Os, suggesting not much current is being injected Nov 08 16:40:49 (it's not just current that can damage I/O cells, static overvoltage can too, but that requires at least 2V or so) Nov 08 16:41:57 btw in case you want to measure the internal 3.3V supply of the BBB (VDD_3V3A, which is the actual supply of the I/O cells), iirc you can measure it at TP4 situated near the PCB edge between the ethernet connector and the 5V barrel jack Nov 08 16:43:37 the most worrisome thing that can happen with current injection is VDD_3V3A being pumped up to being more than 2V above the 1.8V supplies (which can be measured at P9.32) Nov 08 16:43:37 Thanks! Good to know. Nov 08 16:46:39 (like in one test I've done in the past, current injection (which turned out to be about 45 mA via a single I/O) was keeping VDD_3V3A at nearly 2.5V while 1V8 dropped to zero... that was very much not good) Nov 08 18:04:11 all of this could have been avoided if it was a 1.8V IO system Nov 08 18:04:31 that seems unlikely Nov 08 18:05:30 hm? if IO is at 1.8V, you can't bring it above 2V over the 1.8V rail without intentionally doing something bad Nov 08 18:06:26 oh that specific part, sure, but you can still violate power domains and have undesirable current flows Nov 08 18:06:42 in general, sure Nov 08 18:06:44 3.3V does make things worse Nov 08 18:07:07 though 1.8V might get lucky as it is slightly under the Vf of the diodes Nov 08 18:07:46 I don't think the protection diodes have such a large Vf, they'd be useless if they do Nov 08 18:08:57 they are mostly ESD protection anyways Nov 08 18:13:22 iirc from the IBIS data they start to kick in around 0.5V, although I had a lot of trouble getting sensible info from the IBIS data, it seemed rather strange and inconsistent Nov 08 18:16:03 i can't remember what was it that suggested it is around 2V ish range...maybe a full path traverse multiple diodes... never quite understood how to build a 2.0V Vf diode Nov 08 18:18:28 forward biasing a diode the Vf varies by voltage. The diodes are potentially part of a transistor (FET or BJT) as well. It depends on how they designed the structure. Nov 08 18:18:42 Vf varies by current sorry about that. Nov 08 18:18:44 https://docs.google.com/spreadsheets/d/e/2PACX-1vSEol79mIbfHmwragtgqb6SGYvU9i5TAumi2qj9uDKf4TiM6_XkyA3LSFcZB9ETQ0DqlSMsUHT4_-0H/pubchart?oid=799980132&format=interactive Nov 08 18:19:06 good point...that is an exponetial curve Nov 08 18:19:46 sure but already showing substantial current Nov 08 18:20:43 I'm not sure why I cut them off there or whether they continue... I probably didn't bother graphing any further since you're already violating the abs max ratings at that point Nov 08 18:21:07 lemme see if the data continues Nov 08 18:21:29 I suspect you were trying not to destroy the part? Nov 08 18:21:31 hmm, it doesn't seem to Nov 08 18:21:57 GenTooMan: these are graphs based on the IBIS data provided by TI, not based on measurement Nov 08 18:24:43 (specifically this is from model 107, which applies to the lcd_data0-6 and lcd_data12-13 pins when powered at 3.3V±5% with internal pull-up/down disabled) Nov 08 18:29:41 I would have to look at the model to see what they did. I would guess they used approximation diodes on based on the ones used for IO. Even a simple diode still has quite a few parameters. Nov 08 18:31:26 I just remember I had huge trouble with attempting to extract simple V/I diagrams from the (61MB) ibis file Nov 08 18:34:14 The proverbial needle in a hay stack problem. Hmmm interesting problem however. Nov 08 18:36:09 no, just stuff like data missing or making no sense Nov 08 18:36:24 e.g. here's the "driven high" diagram from the same model: https://docs.google.com/spreadsheets/d/e/2PACX-1vSEol79mIbfHmwragtgqb6SGYvU9i5TAumi2qj9uDKf4TiM6_XkyA3LSFcZB9ETQ0DqlSMsUHT4_-0H/pubchart?oid=585477091&format=interactive Nov 08 18:36:38 which makes absolutely no sense Nov 08 18:37:46 it's like everything is shifted by 0.6V (the drop to near-0 mA at 3.3V is because some of the tables end there) Nov 08 18:39:09 maybe I just misunderstood the ibis spec, I dunno (although for some other models I did get results that made sense) ... I was not able to find any free program able to produce these graphs from this ibis file so I had to roll my own Nov 08 18:39:36 (combination of perl script that extracts relevant data + some spreadsheeting) Nov 08 18:42:32 I just started reading on IBIS (darn it zmatt you did that too me again) interesting idea in any case. It looks like they had to readapt it many times however. Nov 08 18:43:33 I have no idea how they produce the ibis file, I'm assuming they have tools that produce it based on the design Nov 08 18:51:58 that appears to be exactly what they do. Nov 08 19:30:59 There are many ways to produce your own graphics on display in system like Arduino, teensy etc (also quite easily like Nextion displays) is there an "easy" (for dummies) method from scratch for Beaglebone also, without install a graphic desktop ? Nov 08 19:31:29 well you wouldn't be searching for anything beaglebone-specific, just linux Nov 08 19:33:50 I think you mean it's more a linux fact , so Nov 08 19:34:37 but I don't know of something like this.... that's why I'm asking... ;-)) Nov 08 20:01:23 zmatt would I be wrong to assume that beaglebone kernels support the linux framebuffer? Nov 08 20:02:13 ehm, obviously they do considering the BBB has HDMI and the default image from factory has X11 installed Nov 08 20:02:37 both the modern drm api and the legacy fb is supported Nov 08 20:02:56 (legacy fb does not support double-buffering or dynamic mode switching) Nov 08 20:05:11 so that would be a good place to start for fred_tv Nov 08 20:05:33 a good place to start would most likely be something higher-level like SDL I'd imagine Nov 08 20:05:45 the low-level APIs are not that user-friendly Nov 08 20:06:02 good point. Nov 08 20:06:10 and SDL is well documented. Nov 08 20:06:22 a while back I was working on a nice wrapper for the modern parts of drm but I haven't finished it Nov 08 20:08:25 hopeful the OP was listening to that :D Nov 08 20:08:30 I would need to display simple numbers or bars for meters (voltmeter , ohmeter , VUmeter etc) Nov 08 20:09:46 to display values collected via adc pins Nov 08 20:12:23 drawing simple graphics/text into a framebuffer is platform-independent code... sdl does include some functions for things like drawing lines and rectangles. for very simple text (e.g. numeric displays) you could just copy rectangles from a texture that contains all 10 digits. general text-rendering requires a fairly heavyweight library like pango Nov 08 20:13:02 something like this but with beagle...https://www.youtube.com/watch?v=ogfWnfjdynk Nov 08 20:14:10 or the use of freetype library Nov 08 20:14:50 freetype is a font library, not a text rendering library. pango uses freetype Nov 08 20:15:24 cairo is a full library for 2d graphics and text (using pango) Nov 08 20:16:59 I did a simple display in Python over i2c. There's libraries for that. I'd have to power mine up and look what I installed, but it's not hard to work it out. Nov 08 20:17:42 Ragnorok: that sounds like the very lowest layer, normally handled by the kernel driver Nov 08 20:18:26 Your framebuffer comment reminded me. The python built an image in buffer and I tossed it at the display vai i2c. Nov 08 20:18:41 Did text and simple shapes. Nov 08 20:19:45 the rendering step is of course independent of how the bits are actually shoveled to the display Nov 08 20:20:06 Sure. So the i2c bit isn't really relevant. There it is. Nov 08 20:20:53 (unless the gpu is used for rendering, then there's some kernel-side magic to ensure the buffer isn't sent to the display controller until the gpu is done rendering into it) Nov 08 20:21:37 It is sounding like something very hard to me to buid up...... Nov 08 20:21:49 *build Nov 08 20:22:44 why? from what you said it sounds like sdl may be quite sufficient Nov 08 20:23:13 I guess it depends on experience. I wouldn't call it "very hard". It's eaiser in python than C++. Nov 08 20:23:28 it's not hard in C++ either Nov 08 20:23:48 Well I didn't want to pull in a pile of libraries, so it was "harder". lol Nov 08 20:24:28 Actually for me it was teletubbie simple. A team mate did that part in C++ and I just plopped it in there. Nov 08 20:24:41 http://wiki.libsdl.org/SDL_RenderDrawLines?highlight=%28%5CbCategoryRender%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29 Nov 08 20:25:07 I mentioned freetype and I have used that for direct generation of text in a buffer. It's all a matter of perspective and experience. Nov 08 20:25:10 this probably needs to be modified a bit to use the framebuffer instead of a "window" Nov 08 20:25:50 GenTooMan: fair, it all depends on how simple or complex your text rendering needs are I guess Nov 08 20:26:35 like I said, for simple numeric displays like fred__tv mentioned, simply blitting prerendered digits may very well be easier than any font library Nov 08 20:27:54 zmatt in terms of simplicity you have a valid point with that. Nov 08 20:28:33 fred__tv the advantage of SDL is you can test it out under PC linux first then build it and run it on the BBB Nov 08 20:31:19 you can also use cairo directly on the legacy framebuffer: https://gitlab.com/cairo/cairo-demos/blob/master/fbdev/cairo-fb.c (except this example will fail since they hardcode CAIRO_FORMAT_ARGB32 instead of actually using the correct pixel format of the framebuffer) Nov 08 20:32:57 (if you mmap /dev/fb0 you simply get an uint16_t[height][width] into which you can scribble your graphics any way you want) Nov 08 20:34:02 at least it'll probably be uint16_t on the BBB Nov 08 20:34:44 (except when using a cape whose lcd is wired up for 24-bit graphics) Nov 08 20:48:42 Well... i'll take a look , first at what SDL is, as you may understand knowledge here is very limited.... **** BEGIN LOGGING AT Fri Nov 08 21:46:43 2019 Nov 08 23:08:48 ds2: I made a post about the Matplotlib on hackster.io. See here: https://www.hackster.io/functt/matplotlib-on-the-beaglebone-black-wireless-088849. Nov 08 23:09:22 I used some ideas from found resources and I changed a bit on the second script to make it accessible via file writes. Nov 08 23:09:22 ... Nov 08 23:09:48 The nice visual is towards the bottom of the page on that link I showed. Nov 08 23:12:02 I can add more info. to make it an actual plot that makes sense but it will take more time. I really just wanted to show people the visual aspect to what Matplotlib can do. So, the BBBW can do it. It only took the file a couple of seconds to complete. Nov 08 23:15:39 ... Nov 08 23:15:50 Oh and look here: https://github.com/deezer/spleeter?_lrsc=f97ec62b-78ff-446e-9f08-c9b2d8a8f55e. Nov 08 23:16:03 It was for DSP users and music lovers alike. Nov 08 23:17:14 I am still waiting to get my hands on that new board so I can test the DSPs and M4s. I wanted to try that spleeter library out. Nov 08 23:27:18 it seems very unlikely that library supports delegating computation to the DSPs (or any other core) on the am572x Nov 08 23:44:37 Oh. Nov 08 23:45:31 So, would I be able to use the DSPs on the newer am572x AI board from BBB.io for spleeter or should I just use the main chip? Nov 08 23:46:37 Oh. Nov 08 23:46:40 I got you now. Nov 08 23:47:18 So, that library would not support the am572x or the DSPs on the AI? Nov 09 01:02:49 Who, what company, mfg. the AI? Nov 09 01:04:17 embest is the cm Nov 09 01:04:22 Oh! Nov 09 01:04:34 What does cm mean? Nov 09 01:04:37 Oh! Nov 09 01:04:39 Current mfg? Nov 09 01:04:55 Contract Manufacture Nov 09 01:04:57 No pun intended! Nov 09 01:04:58 Oh. Nov 09 01:04:59 Okay. Nov 09 01:05:32 +rcn-ee[m]: Are people still complaining about the heat on that board? Nov 09 01:05:49 I cannot connect to the google groups for some reason. Nov 09 01:07:08 I found a way! Just now, I got into it again. Yea boy! Forget the question. Nov 09 01:07:57 is that the only offshore CM for any of the boards? Nov 09 01:08:36 Besides Seeed? Nov 09 01:08:52 GHI still makes the Black, Black Wireless.. Nov 09 01:08:58 and a bunch of capes Nov 09 01:09:52 but seeed only makes a licensed board Nov 09 01:10:56 ds2: that's a jason discussion Nov 09 01:11:46 :D Nov 09 01:54:20 Look here: https://groups.google.com/forum/#!category-topic/beagleboard/newbies/7btEZzm_jKU. Nov 09 01:54:30 I just posted something to rile the peoples. Nov 09 01:57:24 set_: https://www.amazon.com/Exploring-BeagleBone-Techniques-Building-Embedded/dp/1119533163/ Nov 09 02:01:04 Second edition? Nov 09 02:01:09 Nice! Nov 09 02:02:42 What happened to the first edition? Nov 09 02:06:11 Is there a book on how to read TRMs surrounding around the TI based am335x/am572x? Nov 09 02:14:09 I guess I am tired of reading random things w/out direction. My bad. I will delete the post in case the "peoples" are upset now. Nov 09 02:15:05 set_: google groups is an email group, your message has already gone out to 10,000's.. Nov 09 02:16:40 Ut oh. Nov 09 02:16:48 Correction: 12,116 users.. Nov 09 02:17:28 Dang! Well, hopefully this will teach me a lesson. Do not learn things and never reach out to the "peoples." Nov 09 02:18:14 +rcn-ee[m]: 12,000 users could not be wrong. Is anyone trying to fathom a book together? Nov 09 02:18:16 set_: ah really? just because no one has responded in 10 minutes? Don't be rude.. Nov 09 02:18:17 set_ brilliance is the art of planning ahead... Nov 09 02:19:20 10 minutes and counting! Nov 09 02:19:23 Hahhahaha. Nov 09 02:19:49 I am just concerned. Nov 09 02:20:00 I guess I can stop playing granny-do-little now. Nov 09 02:20:25 ? it's a friday night and saturday morning for most of the world's english population.. Nov 09 02:23:02 I understand. I am not fretting over the reply/response just yet. I just do not know why the, which concerns me, bbb.io population is not producing more. I am not so much fretting over the "head honchos" here. I am wondering about the community I guess. Nov 09 02:24:52 For instance, there were many books but the books were fun and informative. Maybe a step in another direction would be teaching a person like me how to go about reading these TRMs and how to react to the info. in them. Nov 09 02:24:53 ... Nov 09 02:25:49 Just a notion. Nov 09 02:54:32 set_ if it were easy everyone would have done it. **** ENDING LOGGING AT Sat Nov 09 02:59:57 2019