**** BEGIN LOGGING AT Sat Jun 29 02:59:57 2019 Jun 29 03:00:09 no such file or dir. Jun 29 03:00:22 Maybe it moved. Jun 29 03:01:04 highly unlkely given that I got this path from https://github.com/imfatant/test which uses exactly the same kernel series as you are Jun 29 03:01:23 but you can look around for the right path of course Jun 29 03:01:27 His kernel is broken or used to be. Jun 29 03:01:28 Okay. Jun 29 03:01:35 I will look for the right path. Jun 29 03:01:41 maybe check ls -d /sys/devices/platform/ocp/*P8_15* Jun 29 03:01:58 actually that *does* look wrong Jun 29 03:02:12 wait maybe it isn't Jun 29 03:02:38 using hardcoded paths into /sys/devices is a bad idea anyway, there's probably a better path to use Jun 29 03:02:48 but I'd need to boot up a bbb with a normal image to check Jun 29 03:02:57 Do not worry about it. Jun 29 03:02:59 I can look around. Jun 29 03:03:19 it should actually be in /sys/devices/platform/ocp/ Jun 29 03:03:23 pretty sure Jun 29 03:03:36 I am in there now. Jun 29 03:04:04 I see the blue dir. of the p8 15 pinmux. Jun 29 03:04:12 There must be more to it than just that. Jun 29 03:04:14 Looking on. Jun 29 03:04:19 ? Jun 29 03:04:33 there should be exactly one dir with "P8_15" in the name Jun 29 03:04:43 There is Jun 29 03:05:46 It states gpio_pu in it. Jun 29 03:05:58 in the state file. Jun 29 03:06:12 obviously, that wasn't the question Jun 29 03:06:14 the name is Jun 29 03:06:18 Right. Jun 29 03:06:43 .... yes? Jun 29 03:07:17 It is /sys/devices/platform/ocp/ocp:P8_15_pinmux/. Jun 29 03:07:50 in other words the path did exist exactly as I typed it earlier Jun 29 03:08:03 Right but the effort failed. Jun 29 03:08:10 and you probably just screwed something up somehow Jun 29 03:08:19 I will try again. Sheesh. Jun 29 03:08:36 I am in the dang dir. now. I will just do it from here. Jun 29 03:10:07 Okay, Okay. You were right. I put a /class dir. in there by accident. Jun 29 03:10:49 Okay. Jun 29 03:11:03 So, I am back to the pruecapin_pu mode of that p8.15 pin. Jun 29 03:11:03 y'know, I'm done with you for today, good luck on your further efforts Jun 29 03:11:10 Hhahahaha. Jun 29 03:11:11 fine. Jun 29 03:11:14 Thank you. Jun 29 03:11:16 anyway. Jun 29 03:11:29 @zmatt: Seriously. Thank you. Jun 29 03:12:01 @zmatt: I warned you about that bike ride. Bouncin'! Jun 29 04:08:40 6.1 +/- out of SBus from my receiver (X8R). Jun 29 04:08:54 Sorry. 6.1v. Jun 29 04:09:15 I think something is erie-Indiana here. Jun 29 04:10:11 @zmatt: If I read tomorrow what you say, will you please like me on facebook. Just playin' man. Let me know something. Jun 29 04:28:05 Seriously. I think what voltage is produced from the BBBlue is coming directly out of the SBus terminal on the X8R. Jun 29 04:28:21 bzzt, bzzt. Jun 29 04:32:25 So, I need to downplay that voltage w/ a couple, very-strong resistors. Jun 29 04:32:29 Math time! Jun 29 04:48:03 set_: you're making absolutely zero sense Jun 29 04:48:16 and no resistors are needed Jun 29 04:58:40 I measured the volts coming out of the X8R. Jun 29 04:58:48 6.1v! Jun 29 04:59:08 This gets accepted by the PRU, right? Jun 29 04:59:11 Oh. Jun 29 04:59:19 Only signal is accepted. I got it. Jun 29 04:59:20 Sorry. Jun 29 05:00:23 So, the signal is the only thing that this PRU src is supposed to recognize? Jun 29 05:22:07 Off to test the signal voltage. Jun 29 05:22:10 Just to make sure. Jun 29 05:26:14 Okay. So, there is exactly 0.0v coming from the signal pin from SBus on the X8R. Jun 29 05:26:57 and all while powered. Jun 29 05:37:09 set_: the signal pin will be 0v while idle yes Jun 29 05:37:29 set_: and correct, you're not doing anything at all with the power output on the sbus connector Jun 29 05:37:58 Okay. Jun 29 05:38:00 Got it. Jun 29 05:38:05 Yikes man... Jun 29 05:38:22 I am off to test out of idle scenarios. Jun 29 05:39:03 set_: if you want to actually verify the voltage range on the sbus signal line, you'd need to connect a scope (with something like 10μs/div time scale, trigger on rising edge) and use the RC transmitter to actually send something Jun 29 05:50:04 Okay. Jun 29 05:50:36 I actually just tested the voltage from the breadboard I am using at 5v while the "throttle" is a full bore. Jun 29 05:50:37 ... Jun 29 05:50:57 I do not think this X8R is for 3.3v input. Jun 29 05:51:05 the power supply output is irrelevant Jun 29 05:51:08 that's just a 5V supply Jun 29 05:51:12 which we don't connect Jun 29 05:51:19 if you look at my schematic Jun 29 05:51:39 I know. But should the signal be at 5v while I am using my commanding gimbal/joystick? Jun 29 05:51:41 B/c it was. Jun 29 05:52:09 what exactly did you measure with what? Jun 29 05:52:18 multimeter. Jun 29 05:52:32 voltage. Jun 29 05:52:36 between what and what? Jun 29 05:52:51 b/t signal and gnd on my breadboard. Jun 29 05:53:08 + = signal and - = GND. Jun 29 05:53:11 + = power Jun 29 05:53:16 Oh. Jun 29 05:53:18 Okay. Jun 29 05:53:24 again LOOK AT MY SCHEMATIC Jun 29 05:53:42 I got it. I need to measure signal somehow like w/ what you were describing. Jun 29 05:53:52 I labeled the pins on the sbus connector, same as on the x8r, and I'm not doing anything whatsoever with the "+" pin Jun 29 05:54:00 I know. Jun 29 05:54:26 I am not using the "+" pin on anything but the + pin on the multimeter. Jun 29 05:54:30 also, a multimeter is not going to be useful for this measurement since it's a data signal, you need a scope Jun 29 05:54:39 oh Jun 29 05:54:40 + or com pin on the...oh. Jun 29 05:54:50 Okay. Jun 29 05:55:25 so you're measuring the two outermost of the three pins on the x8r sbus connector? Jun 29 05:55:53 I have a black and white pin. I am leaving the red pin alone. Jun 29 05:56:06 I thought the white pin, yes. The outer most pins. Jun 29 05:56:22 colors don't mean anything to me Jun 29 05:56:40 @zmatt: The signal and GND are being used. Jun 29 05:56:42 I promise. Jun 29 05:57:35 signal would be 0v normally, and probably pretty randomly fluctuating (but probably never exceeding 3.3v) when transmitting Jun 29 05:57:56 And I used the breadboard to measure the volts via multimeter while moving the joystick. Jun 29 05:57:57 Okay. Jun 29 05:58:06 Then, I need to try another way of getting this measurement. Jun 29 05:58:12 I will use the scope. Jun 29 05:58:56 brb Jun 29 06:00:07 note that claiming the signal is 5v would also be equivalent to saying mirkix is full of shit, since his page says he *tested* the x8r sbus output with the bbblue, and that it has 3.3v output Jun 29 06:02:25 given your history of making mistakes, I'd sooner trust some random guy on the internet who wrote a guide that includes pictures of a working drone with a bbblue in it than I'd trust your attempted measurements :P Jun 29 06:13:24 Okay. Jun 29 06:13:26 Okay. Jun 29 06:13:39 I am new to this machine/Oscope. Jun 29 06:13:51 Let me read back what you typed earlier. Jun 29 06:13:56 One moment. Jun 29 06:15:05 I did try the rising edge but I did not set the 10us/div setting. Jun 29 06:15:21 I will have to read about that in the manual. Jun 29 06:16:44 somewhere you select the timescale, i.e. how zoomed-in you are on the horizontal axis Jun 29 06:17:12 Okay. Jun 29 06:17:39 I found a zoom selection on the second probe setting. Jun 29 06:18:08 Hey @zmatt: What does the /div stand for? Jun 29 06:18:11 sbus is 100kbaud, i.e. 10us per bit-time, so I guess 10us/div may be a bit zoomed in too much actually, maybe 100us/div would be better Jun 29 06:18:16 per grid division Jun 29 06:18:33 100us/div...got it. Jun 29 06:19:52 Off to try again. Brb Jun 29 06:21:05 So, would I need the voltage of a waveform record? Jun 29 06:21:34 Forget it. I found time/div. Jun 29 06:23:54 https://github.com/uzh-rpg/rpg_quadrotor_control/wiki/SBUS-Protocol that image shows basically what you'd expect, except upside down (since it's showing an inverted sbus signal) Jun 29 06:24:12 So, I need the value of the x-axis (horizontal). Right? Jun 29 06:24:26 ? Jun 29 06:24:27 Okay. Jun 29 06:24:45 ? Jun 29 06:25:11 Let me go and look at that photo. Jun 29 06:25:13 notice how here the scope is configured to 20us/div, and as a result the narrowest pulses are half a grid division Jun 29 06:25:46 and it's set to 1V/div vertically, so this is a 3.3V signal Jun 29 06:26:49 Okay. Jun 29 06:27:06 Yea. 1v on my machine is 500%. I got that now. Jun 29 06:27:18 "500%" ? Jun 29 06:27:24 Yep. Weird heh? Jun 29 06:27:51 I have 500, 1000, and some minor numerical values like 50 and below. Jun 29 06:28:22 you are writing words, but they don't assemble to something that has meaning Jun 29 06:28:32 Stop doing this to me. Jun 29 06:28:37 Sorry. Jun 29 06:28:58 wait, why am I still here, I already said a while back I was done with you for today Jun 29 06:29:10 Thank you for showing back up. Jun 29 06:29:21 I'm off again Jun 29 06:29:24 No! Jun 29 06:29:35 Dang it. Jun 29 06:29:49 I am going to test tomorrow. It is later than a something or other over here. Jun 29 06:29:54 Peace! Jun 29 11:26:45 Perl has an open or die syntax that is nice! Jun 29 11:26:53 I cannot wait to use it more w/ the BBB. Jun 29 11:40:37 set_ perl has a nice syntax? Jun 29 14:48:45 I seem to be struggling to get a cape working, I've added it to /boot/uEnv.txt as uboot_overlay_addr3=/lib/firmware/BB-BONE-WTHR-01-00B0.dtbo Jun 29 14:49:13 Also from dmesg I see: uboot_detected_capes=BB-BONE-WTHR-01, Jun 29 14:50:35 the cape doesn't have an identification eeprom? Jun 29 14:50:44 normally you wouldn't need to touch /boot/uEnv.txt at all Jun 29 14:50:54 It might be a me a problem :) Jun 29 14:51:08 Think my cape uses the same pins as UART1 which I had manually enabled.... DOH Jun 29 14:51:41 actually the "uboot_detected_capes=BB-BONE-WTHR-01" suggests you definitely don't need to set uboot_overlay_addr3 manually, u-boot should take care of that Jun 29 14:51:44 lol Jun 29 14:52:26 actually it doesn't look like this cape can conflict with anything Jun 29 14:52:32 it only uses the cape i2c bus Jun 29 14:52:51 yeah, but that's on pins 19,20 ? Jun 29 14:53:36 oh you manually reconfigured those to uart 1 rts/cts use? Jun 29 14:55:58 I hadn't deliberatly but I had enabled UART1 in uEnv.txt Jun 29 14:56:42 you don't need to do anything in uEnv.txt to use an uart either Jun 29 14:57:19 for many purposes you can just /boot/uEnv.txt in its default state Jun 29 14:58:49 I normally just bang my head against a keyboard until the thing works, then leave it in whatever broken state I put it into to get it working :) Jun 29 14:58:56 lol Jun 29 15:04:26 Like people seem to run commands like "for sensor in /sys/bus/i2c/devices/i2c-1/*/*_input; do echo -n "$(basename $sensor): "; cat $sensor; done" Jun 29 15:04:34 but I run that and it's like "nope" Jun 29 15:04:41 wrong i2c bus Jun 29 15:05:04 it's i2c-2 Jun 29 15:06:57 yeah I tried that aswell Jun 29 15:07:20 "*_input: cat: '/sys/bus/i2c/devices/i2c-2/*/*_input': No such file or directory Jun 29 15:07:51 can you share (using a paste service like pastebin.com) the output of ls /sys/bus/i2c/devices/i2c-2 and ls -l /sys/bus/iio/devices Jun 29 15:08:38 actually ls /sys/bus/i2c/devices/i2c-2/* would be more informative than ls /sys/bus/i2c/devices/i2c-2 Jun 29 15:09:56 https://gnxs.uk/2vz3f Jun 29 15:10:33 hum Jun 29 15:10:53 this doesn't look like the overlay is active Jun 29 15:11:09 just checking, are you running from eMMC or SD card? are you using the latest image? Jun 29 15:11:19 Yeah I think I had the overlay active at one point, as I was getting lux readings, but no others Jun 29 15:11:53 eMMC, latest-ish image Jun 29 15:12:35 "ish" ? the latest image is 8 months old, so if you're not running the latest, it's also not latest-ish :P Jun 29 15:12:55 root@arm:/home/debian# uname -a Jun 29 15:13:00 (latest official image anyway, there are more recent testing builds of course) Jun 29 15:13:08 cat /etc/dogtag Jun 29 15:13:17 rcn-ee.net console Debian Image 2019-05-10 Jun 29 15:13:30 you changed the hostname to "arm" ? Jun 29 15:13:41 I dont think so Jun 29 15:13:42 ohhh, you're not running a beagleboard.org image are you Jun 29 15:13:57 My beaglebone has "issues" Jun 29 15:14:17 2Gb eMMC and a fault SD Card slot Jun 29 15:14:31 so I flashed a console image over USB Jun 29 15:14:49 right, my memory sucks so I didn't recognize your name, but I do remember this Jun 29 15:14:58 hah :D Jun 29 15:15:20 pretty sure I already recommended at that time to install the beagleboard.org console image Jun 29 15:15:49 if you expect capes to work then you *really* should have installed the beagleboard.org console image instead of the one you have now :P Jun 29 15:15:58 probably Jun 29 15:16:34 Yeah I think I can detect it using i2c detect Jun 29 15:17:30 in general don't use i2cdetect, i2c is not a discoverable bus and i2cdetect can have weird side-effects Jun 29 15:18:20 I'll go find a different BBB and try and use that Jun 29 15:18:38 the problem isn't the hardware, it's the image you flashed :P Jun 29 15:19:00 see with the uEnv.txt overlay enabled I get lux1 Jun 29 15:19:02 it might be as simple as missing the overlays package, but who knows what else is different Jun 29 15:19:05 hmm Jun 29 15:19:08 that is weird Jun 29 15:19:09 debian@arm:~$ for sensor in /sys/bus/i2c/devices/i2c-*/*/*_input; do echo -n "$(basename $sensor): "; cat $sensor; done Jun 29 15:19:22 I don't understand why autodetection isn't loading the overlay for you Jun 29 15:19:35 especially since it does sound like the cape was autodetected Jun 29 15:20:00 it could just be weird, I bet I could reboot and it would stop working Jun 29 15:20:13 start working you mean? Jun 29 15:20:21 or? Jun 29 15:21:01 anyway, is there a reason to not just reflash to the latest bb.org stretch-console image? https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Console_Snapshot Jun 29 15:21:34 uhmm, I could, just took a while to flash last time Jun 29 15:22:13 well you chose to flash this one instead of the bb.org one :P Jun 29 15:22:59 you could also try just making sure you have the latest bb.org-overlays package, 4.14-ti series kernel from rcn, and maybe u-boot Jun 29 15:23:21 so the overlay was in the firmwares folder Jun 29 15:23:38 yeah, it's part of a debian package created by rcn Jun 29 15:24:07 bb-cape-overlays Jun 29 15:35:41 pretty sure I used the console snapshot lasttime Jun 29 15:38:45 nah, you used the other one Jun 29 15:39:14 (the existence of which was news to me at that time) Jun 29 15:39:38 in the bb.org console image /etc/dogtag says "BeagleBoard.org Debian Image" followed by the date Jun 29 15:39:43 and the default hostname is beaglebone Jun 29 15:43:12 maybe it doesn't matter much, but I don't actually know Jun 29 15:43:22 can you share your current /boot/uEnv.txt ? Jun 29 15:44:05 one sec, trying to boot a different BBB with an sdcard Jun 29 15:53:06 Eurgh no idea what is going on with this one Jun 29 16:07:42 bizzare I cant boot this one of an SD card Jun 29 16:08:08 I can boot my beaglebone pocket off the same SD card, this one won't boot off of it Jun 29 16:08:25 this is a different one to the one with a broken sd card slot lol Jun 29 16:10:24 incase you were wondering, this is what the SD-card boot looks like on this one which is failing: https://gnxs.uk/ma89x Jun 29 16:12:29 that's odd... u-boot had no trouble with the sd card but linux doesn't see it? that's a new one o.O Jun 29 16:13:33 See I manage to break everything lol Jun 29 16:13:54 does it actually wait a bit before saying it gave up? Jun 29 16:14:00 same SD card works fine in my beaglebone pocket for refernce Jun 29 16:14:04 yeah Jun 29 16:14:09 paused at that for like 30seconds? Jun 29 16:14:15 the HDMI message Jun 29 16:14:16 hmm Jun 29 16:15:10 try removing the "quiet" option from the "cmdline" variable in /boot/uEnv.txt Jun 29 16:15:13 to see a bit more info Jun 29 16:15:33 root=/dev/mmcblk0p1 Jun 29 16:15:46 think thats trying to read my eMMC rather than the SD card? Jun 29 16:15:47 yeah that root device is correct Jun 29 16:15:53 no, eMMC is mmcblk1 Jun 29 16:16:00 Ahh fair Jun 29 16:16:20 besides, it would be equally strange for it to be unable to locate the eMMC Jun 29 16:16:27 welll... Jun 29 16:16:39 ubuntu@arm:~$ mount Jun 29 16:17:01 ? Jun 29 16:17:17 that one when booted has root mounted as 0p2 Jun 29 16:17:26 no idea where 0p1 is lol Jun 29 16:17:50 did you paste something multi-line? because if so, only the first line was actually visible Jun 29 16:18:05 ahh Jun 29 16:18:06 that just means ubuntu uses two partitions on the sd card Jun 29 16:18:08 the debian images do not Jun 29 16:18:24 ./dev/mmcblk0p2 on / type ext4 (rw,noatime,errors=remount-ro) Jun 29 16:31:59 this may be a faulty sdcard slot on this one Jun 29 16:32:12 I think holding down the boot button is making contact Jun 29 16:32:24 but then when I let go, the sd card stops responding Jun 29 16:32:25 hah Jun 29 16:32:52 that also suggests you're holding the boot button too long, you can let go the moment the power led turns on Jun 29 16:33:29 (or technically something like 20ms after the power led turns on iirc, but whatever :P ) Jun 29 16:35:29 This is what happens if I let go after boot Jun 29 16:35:31 https://gnxs.uk/l6gp0 Jun 29 16:36:03 hehe, timeout timeout timeout timeout timeout Jun 29 16:36:44 but yeah that does seem like a poor contact or maybe a hairline fracture in something Jun 29 16:37:23 also, please don't hold the sd button this long unless video is disabled in /boot/uEnv.txt Jun 29 16:37:54 the sd button connects one of the lcd data lines to ground via a 100 ohm resistor Jun 29 16:38:32 (I have no idea why they used such a small resistor value instead of something in the range 1K-10K) Jun 29 16:40:02 oh Jun 29 16:40:08 I never have hdmi plugged in Jun 29 16:40:19 but I guess it will still try to use it anyway? Jun 29 16:40:38 hmm, now that you say it like that I guess it probably doesn't Jun 29 16:41:51 but I'm not 100% sure Jun 29 16:42:52 regardless, there's _normally_ no reason to press the sd button once the board is powered up Jun 29 19:28:18 GenTooMan: No...but it seems like something to learn to test out. Jun 29 19:28:44 There must be reasons to use it or it would not be around. Jun 29 20:38:28 @zmatt: I checked the Oscope to test the 100us/div for the signal and gnd on the SBus of the X8R receiver. Jun 29 20:38:29 ... Jun 29 20:38:43 Can I say something? Aw! Jun 29 20:39:59 The signal on the Oscope is so tiny. I cannot figure out if the signal is like what the photo shows on the invert SBus on github. Jun 29 20:40:21 i.e. the opposite of the inverted signal. Jun 29 20:40:46 then adjust the timescale until it's not tiny? Jun 29 20:41:05 timescale. Okay. Off to look that up. Jun 29 20:41:15 what the signal looks like isn't what you were looking anyway, you were interested in the voltage range Jun 29 20:42:14 @zmatt: Okay. Jun 29 20:42:38 Maybe we should wait a couple of days for this idea to come to fruition. My Oscope skills are less than nice. Jun 29 20:43:08 I pushed every button on that damn thing like an ape. No workie so far. Jun 29 20:43:20 Back to the manual. Jun 29 20:43:48 pushing every button like an ape indeed sounds like a great way to accomplish absolutely nothing Jun 29 20:44:02 Ha. Jun 29 20:44:15 Hey...so the timescale should be at 500us or something? Jun 29 20:44:29 that's zooming out, not zooming in Jun 29 20:44:32 At 100us, the timescale is still small. Jun 29 20:44:33 Oh. Jun 29 20:44:37 Okay. Jun 29 20:44:43 Thank you for the info. Jun 29 20:44:50 note that the scope pic on that wiki page was 20us/div Jun 29 20:44:56 Aw. Jun 29 20:45:06 (it says so on screen) Jun 29 20:46:15 I have been using 100us/div the entire time thinking I was a concubine. Jun 29 20:46:17 Okay. Jun 29 20:46:20 brb Jun 29 20:47:14 what scope are you using? Jun 29 21:01:16 Right I am back :D so I have reflashed to "BeagleBoard.org Debian Image 2019-06-23" same issues, with default uEnv.txt I see nothing, with the dtbo manually put in I get lux only but no other sensors Jun 29 21:05:42 Actually it might be working: /sys/bus/i2c/drivers/bmp280/2-0077/iio\:device2/in_temp_input Jun 29 21:06:35 what does u-boot say when using the default uEnv.txt ? Jun 29 21:06:55 @zmatt: Rigol # DS1102E. Jun 29 21:07:29 I got the measurement to show more like an actual measurement this time. Let me review our last conversation and then I will try to get back to you later. Jun 29 21:07:40 To the logs! Jun 29 21:07:42 Jonnyw2k[Web]: that's a weird path to access that device btw :P using /sys/bus/iio/devices/ is probably more convenient Jun 29 21:07:49 no idea, but using the iio devices rather than the i2c method worked Jun 29 21:07:54 yeah I googled IIO Jun 29 21:08:14 https://gnxs.uk/8a5mg Jun 29 21:12:42 that still leaves the question of why it's not working plug&play (as it should), can you check the u-boot output when using the default /boot/uEnv.txt ? (i.e. no manual configuration of the dtbo) Jun 29 21:13:12 not sure, how do I do that without a serial cable (cant plug in serial cable and cape at same time) Jun 29 21:13:27 ah Jun 29 21:14:59 is it revision A or B of the weather cape? Jun 29 21:15:04 I presume B Jun 29 21:17:06 trigger on rising edge and about 10 or 20us/div. Got it. Should I use my probe from the Oscope on chan1, chan2, or trigger? @zmatt: When you are done working w/ the weatherCape issue, I will get back to this chat. Jun 29 21:18:00 set_: channel 1 or 2 doesn't matter, they're just two channels for measuring two things at the same time (which you don't need right now) Jun 29 21:18:13 Okay. Jun 29 21:18:26 You would be amazed at how little I actually have applied knowledge. Jun 29 21:18:27 Okay. Jun 29 21:18:37 trigger! Jun 29 21:20:56 Jonnyw2k[Web]: you can also check the cape's identification eeprom with /opt/scripts/device/bone/capes/cape_eeprom_check.sh Jun 29 21:22:22 It identified I can see that in dmesg with standard uEnv.txt Jun 29 21:22:38 yes but that didn't indicate the version Jun 29 21:22:44 Ahh Jun 29 21:23:15 I'll have a look once my node-red install is done Jun 29 21:34:06 @zmatt: Okay. I have good and bad news. Which do you want first? Jun 29 21:34:29 I'm perfectly fine with neither Jun 29 21:34:38 Okay but it is juicy! Jun 29 21:35:04 Well, the receiver is dead. For what reason, no clue. Jun 29 21:35:27 On the other hand, I have grown accustomed to my Oscope. Jun 29 21:35:52 Luckily, I have back up. Jun 29 22:07:39 hh Jun 29 22:10:09 oops wrong window **** ENDING LOGGING AT Sun Jun 30 03:00:18 2019