**** BEGIN LOGGING AT Fri Sep 11 02:59:57 2020 **** BEGIN LOGGING AT Fri Sep 11 03:02:19 2020 Sep 11 03:02:35 im waiting on 3s batteries Sep 11 03:02:40 was using 2s Sep 11 03:02:45 for testing Sep 11 03:03:29 i have not had all 4 legs off the groud yet Sep 11 03:03:35 ground Sep 11 03:06:40 is pretty close Sep 11 03:07:01 flipped over nicely a couple times Sep 11 03:07:54 nice Sep 11 03:08:04 how much has it cost you total Sep 11 03:08:11 i may try it myself Sep 11 03:09:29 more than 500 us dollars Sep 11 03:10:37 about 300 of it was 2 beaglebone blues and the tiny ass wires/connectors Sep 11 03:10:50 lol Sep 11 03:11:02 pic of the build? Sep 11 03:12:47 sec Sep 11 03:14:06 https://imgur.com/2V4rJOq.png Sep 11 03:14:11 how it sits right now Sep 11 03:14:27 10" props Sep 11 03:14:53 held together with zip ties Sep 11 03:14:58 no screws Sep 11 03:15:04 except the motors Sep 11 03:16:09 i have a camera and stuff just have not purchased the fpx transmitter/receiver yet Sep 11 03:16:16 fpv Sep 11 03:20:57 nice Sep 11 03:21:35 any idea how intensive on cpu wireguard is? would i be able to run it and the flight controller without falling from the sky? Sep 11 03:24:41 no clue i am a complete noob Sep 11 03:24:49 that is why my wiring looks like crap Sep 11 03:24:51 im also pretty noob Sep 11 03:25:02 but im old Sep 11 03:25:07 gotta start somewhere Sep 11 03:25:10 define old Sep 11 03:26:48 had a 20 year class reunion Sep 11 03:27:27 you still good man Sep 11 03:27:32 aarp card Sep 11 03:27:35 lol Sep 11 03:27:46 that is when you can think about getting old Sep 11 03:28:13 yeah i guess **** BEGIN LOGGING AT Fri Sep 11 04:29:57 2020 **** BEGIN LOGGING AT Fri Sep 11 06:52:23 2020 Sep 11 09:03:46 Hello **** BEGIN LOGGING AT Fri Sep 11 09:47:18 2020 **** BEGIN LOGGING AT Fri Sep 11 10:04:50 2020 **** BEGIN LOGGING AT Fri Sep 11 11:13:42 2020 **** BEGIN LOGGING AT Fri Sep 11 13:01:33 2020 **** BEGIN LOGGING AT Fri Sep 11 15:59:32 2020 **** BEGIN LOGGING AT Fri Sep 11 16:50:32 2020 **** BEGIN LOGGING AT Fri Sep 11 19:35:39 2020 **** BEGIN LOGGING AT Fri Sep 11 21:16:24 2020 Sep 11 21:30:27 e **** BEGIN LOGGING AT Fri Sep 11 22:40:24 2020 Sep 12 00:58:30 hi Sep 12 01:41:59 is there a way to turn off the power output when using lipo Sep 12 01:42:12 on beaglebone blue Sep 12 01:42:52 like when i press the power button to turn off, the computer turn off but like my gps and receiver do not Sep 12 01:43:23 they are plugged in to the gps port and the power connector respectively Sep 12 01:44:46 renrelkha: there are distinct "always-on 5V" (not switched off) and "system 5V" (switched off when the beaglebone is off) supplies... the always-on 5V is quite dangerous to use (e.g. using it for a GPS receiver connected to the GPS connector is a recipe for damaging the AM335x) yet obnoxiously it seems to be the most widely available Sep 12 01:46:34 ah, I knew I had a sketch of the power tree somewhere... https://photos.app.goo.gl/6SyBtF3oUzcwn5G98 Sep 12 01:46:41 the gps is only connected to the gps connector and i2c. i do have the rc receiver on the black port 5v power Sep 12 01:48:00 yeah the GPS header (which I accidently called "GSM" in the drawing) uses the always-on 5V supply, which is a really bad design decision Sep 12 01:48:45 if the GPS module is powered from that header, DO NOT power off the beaglebone blue Sep 12 01:48:50 so should i supply alternate 5v power source for those components? Sep 12 01:49:46 what happens if i turn off the beaglebone? Sep 12 01:49:56 i have several times.... Sep 12 01:50:26 power continues to be supplied, hence the GPS module will continue to drive its output into the beaglebone blue while it's powered off Sep 12 01:52:01 does sudden power loss matter like will things get corrupted Sep 12 01:53:40 (and driving I/O high while the beaglebone is unpowered can easily damage the processor, but it'll depend on how much current ends up flowing and how long this situation persists) Sep 12 01:53:56 sudden power loss of what? Sep 12 01:54:35 arduino i can just unplug at any sane time and nothing bad will happen Sep 12 01:55:13 rpi does not like sudden power loss Sep 12 01:55:15 of the beaglebone you mean? Sep 12 01:55:19 ah Sep 12 01:55:26 it'll depend a bit Sep 12 01:56:03 though I generally just unplug beaglebones myself and almost never bother with politely shutting them down Sep 12 01:56:52 ok Sep 12 01:58:02 im running like debian 10 dev console version with real time kernel Sep 12 01:58:03 however if this happens while data is being written to eMMC, afaik there is a risk of filesystem corruption in a way that ext4 journaling may not be able to defend against due to how MLC NAND flash works Sep 12 01:59:41 once i realized the power button safely shuts it down i have been using it Sep 12 02:00:24 for our products (which embed a beaglebone black and which are _never_ shut down cleanly) we reconfigure the eMMC into SLC mode with "reliable writes" enabled just to be on the safe side (but switching eMMC to SLC mode sacrifices 50% of its space) Sep 12 02:00:29 until that point i was either pulling the plug or command line power off Sep 12 02:00:44 commandline "poweroff" is clean shutdown Sep 12 02:00:48 same as button Sep 12 02:01:14 which, generally speaking, is of course still preferred Sep 12 02:01:43 i assumed but did not know for sure Sep 12 02:01:56 if you don't you may also lose data that was written within a short period before the power loss Sep 12 02:02:14 the blue with its dreadful always-on 5V power supply however seriously complicates the situation Sep 12 02:03:12 should i just power them from another source Sep 12 02:03:20 and I just checked the schematic... it seems sys_5v is literally not even available on any header, just on a test point *rolls eyes* Sep 12 02:03:58 if possible/appropriate use the beaglebone's 3.3V supply for external electronics that's connected to it Sep 12 02:05:18 the 6V supply on the servo header is also safe since it's under software control hence automatically disables when the processor is reset or powered off Sep 12 02:06:05 i do not have servo power enabled Sep 12 02:07:28 are there any pins that go hot when it is powered on? could use one to trigger a mosfet to power them from the power header Sep 12 02:07:50 I mean, it's simply a 6V supply (powered from vbat) that you can use for whatever, whether you do is up to you :P Sep 12 02:09:51 i appreciate your help Sep 12 02:09:56 thanks Sep 12 02:10:11 on normal beaglebones you'd typically use the reset signal for that, but it looks like that's not available on any connector on the blue Sep 12 02:12:11 using the 3.3v supply (or, more or less equivalently, a gpio with default pull-up) as enable-signal for an external power switch has potential for some tricky problems Sep 12 02:12:27 yeah Sep 12 02:13:02 loss of control and navigation on an autonomous drone is not a good thing Sep 12 02:13:31 in general, power domain crossing (i.e. interconnecting electronics supplied from different supplies) can be really tricky and requires a lot of care and attention... that's why I'd generally recommend using the beaglebone's 3.3V supply for external electronics whenever this is feasible, or use some generic way to cross signals between power domains, like a level shifter Sep 12 02:15:21 maybe i will just put them on a switch Sep 12 02:16:10 inserting a power switch does not magically solve power domain issues Sep 12 02:17:15 (in fact it can create new ones) Sep 12 02:18:28 i would not expect issue if i put switch in 5v feed to each item Sep 12 02:18:49 leaving it powered as it is Sep 12 02:20:08 it entirely depends on the item being switched, what sort of signals are going between it and the beaglebone, and what you are using to control the switch Sep 12 02:21:51 the gps is uart and i2c i guess and the receiver is connected to the m4 plug read by pru Sep 12 02:21:51 unfortunately power domain crossing has no one-size-fits-all solution, there are lots of ways of dealing with it and it all depends on the requirements/constraints of the components being interconnected Sep 12 02:22:14 i would physically switch the switch Sep 12 02:22:15 i2c is relatively safe since it's an open-drain bus Sep 12 02:23:22 you mean manually switch the power of the external components? that sounds pretty error-prone and hazardous Sep 12 02:25:18 e.g. during boot the beaglebone's uart2 txd signal to the GPS will be driven high by the beaglebone, so if the GPS module is unpowered at that moment you're driving the serial input of the GPS module high while it's unpowered Sep 12 02:27:04 in that case i would get it booted and turned on and it wouldnt fly because gps failed to fix Sep 12 02:27:13 now maybe the GPS module is fine with that, I guess that depends on the module. alternatiely it might damage the gps module, or the beaglebone might end up powering the GPS module via (the protection diode on) its serial input pin, which almost certainly means you'd be drawing excessive current from the beaglebone's serial pin Sep 12 02:29:46 I'm not really concerned about whether the software works in a particular configuration or not, I'm talking about avoiding hardware damage Sep 12 02:31:50 I was just illustrating that putting external components behind a power switch does not automatically solve problems... it might solve the issue of external components driving a high signal into the beaglebone, but it may open up the risk of the converse happening Sep 12 02:32:05 yeah i understand, i dont really want to damage the gps but meh its just 20 bucks. i do want to not buy another 115 dollar blue. Sep 12 02:32:25 as I illustrated it also doesn't guarantee the beaglebone is safe Sep 12 02:33:05 yes i understand i wans giving it thought during my long pause in reply Sep 12 02:33:28 the only simple, universal, headache-free way of handling power domain crossing is not having one in the first place, i.e. using the same supply for both (i.e. the 3.3V) Sep 12 02:33:50 with a step up converter or what do you mean Sep 12 02:34:03 they are 5v Sep 12 02:34:44 if the module requires 5V then you're out of luck on that option, since it means it internally generates its 3.3V supply Sep 12 02:38:13 switching module power can fix the issue, but to guarantee safety you'd need to ensure the module is powered before the uart2 pins on the beaglebone are configured, and I'm not quite sure what the best option for that would be... other than the reset-signal, which doesn't seem to be accessible on the blue Sep 12 02:38:46 so what i use a level shifter on the signal wires with both the high and low side powered by beaglebone @ 3.3v and get 5v power somewhere else Sep 12 02:40:26 (i have level shifter premade on little pcbs Sep 12 02:40:30 so, normally a level shifter can always be used to fix power domains, but these weirdass gps modules complicate the picture by using 3.3V I/O yet using 5V power Sep 12 02:41:11 it depends on what's going on inside the module exactly, what its electrical characteristics are Sep 12 02:42:02 normally you'd power each side of the level shifter using the I/O supply of the signals on that side of the level shifter... but the gps module's I/O supply is inaccessible. Sep 12 02:42:05 *sigh* Sep 12 02:42:14 who designed crap interfaces like this Sep 12 02:43:04 if you're lucky maybe the gps module's serial interface is designed to be robust against overvoltage Sep 12 02:43:27 do you have a part number or webpage for tha module you're using? Sep 12 02:43:48 it is working now with the signal levels direct plugged in to the blus id assume they would continue to work with that side powered by the blue too? Sep 12 02:44:18 ehh I don't understand the question Sep 12 02:47:02 I just looked up some random gps module... it doesn't seem like its serial input is designed to be robust against overvoltage. of course not, that would make things too easy Sep 12 02:47:21 level shifter 3.3v both sides powered by blue. i dont see how the signal that would come out of level shifter to gps would be different than how signal is now directly connected without level shifter. Sep 12 02:47:43 having a level shifter with both sides powered from the same supply is completely pointless Sep 12 02:47:54 or, well, that's just called a buffer, not a level shifter :P Sep 12 02:48:15 and as long as the 3.3v shuts off when powered off it would not send signals across Sep 12 02:48:57 it should protect the beaglebone, it wouldn't protect the gps module Sep 12 02:49:45 (unless it's a bidirectional level shifter, then it will not protect the beaglebone either) Sep 12 02:51:58 i do not understand why it would not but i dont really understand how they work i guess wither Sep 12 02:52:02 either Sep 12 02:52:38 so, same scenario as before: BBB powered with serial port configured (hence uart2 is driven high), GPS module powered off Sep 12 02:52:53 ok Sep 12 02:53:11 not worried about screwing the gps Sep 12 02:54:12 if you're power both sides of the level shifter from the beaglebone, then if it's a normal (unidirectional) level shifter then it just buffers the serial output of the BBB and drives it into the unpowered GPS module (and probably more strongly than the BBB would have), risking damage to the GPS module Sep 12 02:55:24 at that point i would purchase a 3.3v replacement Sep 12 02:55:38 would the beaglebone be protected tho Sep 12 02:56:03 if blue off and gps is powered would signal get to blue Sep 12 02:56:45 no, the level shifter would prevent that Sep 12 02:57:30 ok Sep 12 02:57:36 (although not all level shifters tolerate getting a higher voltage on its input than the supply voltage, so you might still end up having trouble depending on the electrical characteristics of the level shifter) Sep 12 02:58:29 all the signals are 3.3v Sep 12 02:59:07 which is higher than the 0V on the level shifter's supplies that you're providing from the unpowered beaglebone Sep 12 02:59:18 oic Sep 12 02:59:50 i do understand that **** ENDING LOGGING AT Sat Sep 12 02:59:57 2020