**** BEGIN LOGGING AT Fri Apr 05 02:59:57 2019 Apr 05 03:21:49 so, I know on the beaglebone black some signals brought out to the header are used for other things like e.g. hdmi. Is there a similar list for the beaglebone green wireless? Apr 05 03:22:38 Green Wireless has some signals on the header that are used by the WiFi chip. Apr 05 03:25:16 yeah, I'll definately want to avoid those. do you know where I can find a chart listing these? (i'm just trying to make sure that the pru pins don't conflict) Apr 05 03:27:12 did you miss my message because of connection issues? (should I repeat?) Apr 05 04:13:49 Kitlith: in general, having patience is a better idea than repeating a question Apr 05 04:14:09 hey zmatt Apr 05 04:14:38 i only asked if I should repeat since the person I was talking to disconnected and then reconnected shortly afterwards Apr 05 04:14:43 how've you been? Apr 05 04:16:15 and the green-wireless is pretty awful yeah... the fact that they don't actually document the fact that the green-wireless occupies many pins on its product page (and instead just copied the drawings for the green) is particularly embarrassing Apr 05 04:20:00 to see which pins are used for what, this commit (which patches my show-pins script to change the pin descriptions of the bbb to those of the bbgw) may be useful: https://github.com/mvduin/bbb-pin-utils/commit/575d62da Apr 05 04:20:28 (scroll the diff to the right, the pin description is the last column) Apr 05 04:20:43 thanks Apr 05 04:21:37 also, one of the top google results I got was: https://elinux.org/EBC_Exercise_10b_Green_Wireless_Pins_Used Apr 05 04:22:57 hmm, looks like that wiki page missed one... (P9.15), unless my commit is wrong Apr 05 04:23:35 d'oh, i forgot to check google instead of duck duck go... kept finding results for the black >_> Apr 05 04:25:16 I used a verbatim search for: beaglebone green wireless pins Apr 05 04:26:25 uhh what Apr 05 04:26:48 ahh, they just didn't connect that signal to P9.15 Apr 05 04:27:10 so P9.15 is still available for use, but with reduced functionality Apr 05 04:29:15 here, fixed... https://github.com/mvduin/bbb-pin-utils/commit/bb573ab9 Apr 05 04:32:31 looks like the pru1 pins [0:11] are home free, which is awesome Apr 05 04:51:51 would linux 'get mad' if the pru changed some pinmux configuration out from under it without talking to the kernel? Apr 05 04:52:31 pru can't change the pinmux configuration Apr 05 04:52:46 the control module ignores unprivileged writes Apr 05 04:53:24 oh. right. that's where the "crazy dma hacks" idea came from. Apr 05 04:53:30 i knew there was a reason for that. Apr 05 04:54:26 and I don't think the kernel will care, but you could consider disabling the relevant pinmux helper nodes using an overlay, if you have cape-universal enabled Apr 05 04:55:19 Hi, i meet a problem with my beaglebone black wireless which is my pc can only detect it everytime it finished flash. When i pull the usb out and plug it again, it doesn't work anymore. Is that any problem with my beaglebone black wireless? Apr 05 04:57:05 student001: that sounds rather odd. can you describe exactly the steps that you do? Apr 05 04:57:37 you're saying that the first boot after flashing it works, but the second boot it doesn't? and you didn't do anything in between? Apr 05 04:58:25 ya, exactly Apr 05 04:58:48 that sounds very mysterious Apr 05 04:59:21 it is probably a good idea to let it run for at least a few minutes the first time though. there's some one-time setup it does on first boot Apr 05 04:59:24 i think i'll just send an event to the host and and have it change the pinmux normally, last couple of times I tried to look into 'crazy dma hacks' (thank you for trying to help me those other two times!) i failed to wrap my head around everything that needed to be done and just ended up dropping it. Apr 05 04:59:50 Kitlith: there's a reason crazy dma hacks are "crazy" Apr 05 05:00:03 yeah. Apr 05 05:00:31 and I was 'crazy' to think that I could really pull it off. Apr 05 05:05:37 did I give you my headers back then? Apr 05 05:05:46 yup Apr 05 05:06:09 did I give an example? Apr 05 05:06:37 mmmmmmmmm, i don't remember. maybe? Apr 05 05:09:10 for future reference I made an overview of BBB vs BBGW: https://pastebin.com/raw/Fi8Vh0n5 Apr 05 05:32:47 Kitlith: https://pastebin.com/GJc1WdD2 this uses my edma headers along with https://github.com/dutchanddutch/jbang/blob/master/src/privileged.h Apr 05 05:33:18 this doesn't include a completion irq back to pruss. it is possible to set that up too though Apr 05 05:37:25 wait, I messed up Apr 05 05:39:37 okay, well, I guess I can come back to that idea later Apr 05 05:40:00 'premature optimization is the root of all evil', as they say Apr 05 05:41:50 ok, there is a non-zero probability it is correct now. I now also enable the irq Apr 05 05:43:21 yeah it all depends on how quickly you need to be able to switch pin direction Apr 05 05:45:30 that is still something I'm concerned about, but I think I should just benchmark it and see how long stuff takes instead of jumping immediately to Fastest but Involved solution Apr 05 05:46:35 I'll be impressed if you can make it change pinmux within 0.1ms of pru requesting it Apr 05 05:47:29 ... well if it's (probably) *that* slow Apr 05 05:47:42 *sigh* Apr 05 05:48:03 actually no sorry, 0.05ms will impress me, especially if you get it consistently Apr 05 05:48:12 (that would undoubtedly require an RT kernel) Apr 05 05:49:44 although I actually wouldn't be surprised if it would end up being 0.1ms Apr 05 05:49:47 oh, that's a bit better. i don't remember what timing window I have between recieving the command and sending a response atmrn, Apr 05 05:50:25 (doing it via EDMA is probably a fraction of a microsecond) Apr 05 05:50:44 (probably a small fraction) Apr 05 05:50:44 let me just write the basic idea of the pru code first, lol Apr 05 06:27:51 hm, given that my whole idea is that I can forward the command to the host so it can decide what to do instead of the pru deciding what to do, i hope there's enough time for the host to recieve data and (get ready to) send data back *anyway* Apr 05 06:29:44 though I suppose I could work around that by keeping the first block of anything I might possibly send in memory at all times, giving some leeway for the host to send the rest of the data Apr 05 06:37:56 who knows, maybe the latency of delivering an interrupt to userspace has improved since I measured it (quite a while ago) Apr 05 06:57:22 welp. that's why I was so insistent on crazy hacks before. Just looked up an old logic capture, and lo and behold there's no time between cmd and data. on a clk measured in Mhz. *sigh* Apr 05 06:58:38 Hi there Apr 05 06:58:46 o/ Apr 05 06:59:07 i am using beagle board x15 Apr 05 07:00:13 i find it difficult to download https://cdn.download.clearlinux.org/latest using CURL command in Python3 Apr 05 07:00:38 always failed to connect to this URL Apr 05 07:01:09 i need to set the company proxy which I've already did. Apr 05 07:01:57 to compare with other system like desktop, i am able to use CURL command to download the URL. Apr 05 07:02:14 Unfortunately, not for Beagleboard Apr 05 07:02:25 is the system date set correctly? Apr 05 07:02:26 please advice. appreciate that Apr 05 07:02:47 oh Apr 05 07:02:50 normally it will use ntp to set the date and time automatically, but if you don't have internet access then that won't work Apr 05 07:02:56 i think i did not set the current date Apr 05 07:03:26 the beagleboard-x15 does not have a battery to maintain the date and time when it is powered off, so after each power on it will need to be set correctly Apr 05 07:03:44 I suggest configuring it to use an NTP server on your local network Apr 05 07:04:13 i see... just a quick one how to configure the date using NTP server? Apr 05 07:04:22 what's the command line? Apr 05 07:05:38 thanks Apr 05 07:06:05 I think the beagleboard images use systemd-timesyncd by default, so you can configure one or more ntp servers in /etc/systemd/timesyncd.conf Apr 05 07:08:01 ok. thanks! Apr 05 07:09:24 you can check on the status of systemd-timesyncd using'timedatectl timesync-status' Apr 05 11:14:59 Hmm, have a strange issue with the CBB-Serial-r02 cape on a BBBlack Apr 05 11:15:58 RS485 RE/DE. If low it causes the driver to "short" A and B lines, if high it releases. Apr 05 11:16:23 If low I cannot send anything on RS485, if high I can send...? Apr 05 11:20:01 uhh no the opposite of course.. the "short" is it driving the bus Apr 05 11:21:18 DE/RE should mean high, then DE (Driver Enable) is active, when low RE (Receive Enable) is active Apr 05 11:21:53 wait, you're seeing the opposite behaviour? Apr 05 11:22:13 Hmm, I seem to have confused myself here. These bias and termination resistors are confusing me now Apr 05 11:22:57 how are you (attempting to) determine the board's output impedance? (i.e. whether it's "shorted" or not) Apr 05 11:23:05 It *does* seem to do what it should... Apr 05 11:24:09 Time to some lunch - My brain is not enabled right now... Sorry to disturb you zmatt Apr 05 11:24:14 lol Apr 05 11:25:04 oh it's this godawful mess of a cape Apr 05 11:25:50 or wait, is it one I'm thinking of... Apr 05 11:25:53 maybe not Apr 05 11:26:25 nm this isn't the same one Apr 05 12:01:18 zmatt, Apr 05 12:01:23 woops, sorry Apr 05 12:01:26 premature Apr 05 12:24:13 Lunch can do all the difference in the world :-D - Impedance Ok now, I used too large resistance values for bias. Apr 05 12:24:54 ... and forgot that the CBB had it's own termination resistor Apr 05 12:28:38 lol Apr 05 12:29:02 and yeah, normally if you want the bus to be biased, you'd combine termination and biasing Apr 05 12:29:37 since if you already have termination on the bus, adding sufficiently strong biasing may lower the impedance too much Apr 05 12:29:47 Yes Apr 05 12:31:04 The CBB has the prescripted 120 ohm, but the bias/termination block that I made used much larger resistance values, which caused a released bus to have voltage close to zero, which I misinterpreted... Apr 05 12:32:21 Using the Pymodbus Synchronous Client now gives signals I like/understand Apr 05 12:37:42 kinda weird they included fixed termination anyway, for many applications you wouldn't want that Apr 05 12:38:38 based on a quick glance at the "modbus over serial line" spec, termination and biasing is considered to be part of the bus and not part of any device (including the master) Apr 05 12:41:57 biasing resistors are specified to be between 450 and 650 ohm. termination is specified to either be 150 ohm resistor, or 120 ohm resistor in series with 1 nF capacitor Apr 05 12:55:34 CBB has an on-board, undocumented, 120ohm resistor, but no biasing. I made external bias with 390 ohms Apr 05 12:56:39 well it's documented in the schematic ;) Apr 05 12:57:23 Oh? Apr 05 12:57:47 (which is the only documentation I've looked at) Apr 05 12:58:18 *blush* indeed there is a schematic Apr 05 12:58:27 I searched the manual... Apr 05 12:59:04 Now I've got a copy of the schematic - Thanks :) Apr 05 12:59:59 using two 390 ohm resistors for biasing lowers the termination impedance from 120 ohm to 90 ohm Apr 05 13:00:07 Yes Apr 05 13:00:42 Hmmm. Apr 05 13:01:02 you could add series resistors (15 ohm on each line) to compensate Apr 05 13:01:04 75 ohms? Apr 05 13:01:16 Ah no Apr 05 13:01:18 no Apr 05 13:01:22 You're right Apr 05 13:01:25 the biasing resistors are effectively in series Apr 05 13:01:31 yes Apr 05 13:01:47 I almost made the same mistake :) Apr 05 13:05:17 90 ohm probably works fine too, especially if the characteristic impedance of the cable is actually 100 ohm nominally (e.g. cat-5). might cause some slight ringing though Apr 05 13:05:52 I wonder what the reasoning is behind the values I quoted above Apr 05 13:08:13 Wouldn't 120 ohm in parallel with 2 x 390 in series become 104 ohms? Apr 05 13:08:53 Anyway, right now I've reached the point where I can start to implement a ModBus slave on an AVR controller :) Apr 05 13:08:54 you're right! I goofed Apr 05 13:08:55 typo Apr 05 13:09:22 That's the first time today I'm right about anything :) Apr 05 13:09:26 lol Apr 05 16:43:57 m Apr 05 18:54:34 test 123 Apr 05 18:54:43 success? Apr 05 18:54:49 yes thanks! Apr 05 18:55:12 Folks I'm trying to SSH to a BeableBone Pocket over USB from Ubuntu 18.04 Apr 05 18:55:44 not able to ping the device Apr 05 18:56:51 using 192.168.6.2 Apr 05 18:57:06 can you pastebin the output of the "ip addr" command? Apr 05 18:57:42 aleak@sing ~> ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: mtu 1500 qdisc fq_codel state UP group default qlen 1000 lin Apr 05 18:57:53 don't paste multi-line output into chat Apr 05 18:58:02 it gets truncated and generally becomes a mess Apr 05 18:58:07 use a paste service such as pastebin.com Apr 05 18:58:11 sorry - pastebin - RTFC Apr 05 18:58:14 hold one min... Apr 05 18:59:02 you're using the latest debian (stretch-iot) image for the pocketbeagle? does it seem to boot normally? (led activity that appears to be blinking happily) Apr 05 18:59:24 here's the pastebin URL Apr 05 18:59:26 https://pastebin.com/NJUFQ3gX Apr 05 19:00:03 uhh, what on earth is this Apr 05 19:00:33 device has heartbeat flash on USR0 and rapid blinking on USR2 Apr 05 19:00:50 is this ubuntu running in a VM or something? or what on earth are all these interfaces Apr 05 19:01:24 no it's on a bare metal machine but I do run VirtualBox which creates a bunch of IP devices Apr 05 19:01:29 hmm Apr 05 19:01:35 no usb networking interfaces though Apr 05 19:01:39 check kernel log Apr 05 19:01:49 ok will do Apr 05 19:02:11 BTW I'm using the latest debian from http://bbb.io/latest (non-gui version) Apr 05 19:02:12 (and/or lsusb) Apr 05 19:02:15 ok Apr 05 19:02:39 it should show up as two network interface + mass storage + serial Apr 05 19:04:22 here's the output from lsusb Apr 05 19:04:32 https://pastebin.com/PB5LAbvx Apr 05 19:05:57 no sign of the beaglebone Apr 05 19:06:15 nope Apr 05 19:06:52 beaglebone would be 1d6b:0104 Apr 05 19:07:39 so maybe unplug and replug the beaglebone while monitoring your kernel log (dmesg -w) Apr 05 19:08:05 doing it now thanks for the cmd... Apr 05 19:08:59 nope big fat zero I'll try it on another machine... Apr 05 19:09:37 are you using the usb cable that came with the pocketbeagle? (assuming they include one, no idea honestly) Apr 05 19:09:44 more generally, try a different cable Apr 05 19:10:06 didn't get a cable with the pocketbeagle but I'll try a different cable now... Apr 05 19:11:44 ah haa! we have some action with the new cable... Apr 05 19:11:54 :D Apr 05 19:12:12 maybe equip the previous cable with a label saying "Charging only, no data" Apr 05 19:12:18 yeah Apr 05 19:13:10 I CAN SSH! Apr 05 19:13:16 or better yet, give it a new home in the trash bin after cutting it to study it fascinating innards and make sure noone will be tempted to rescue it Apr 05 19:13:34 breaking out my scissors now Apr 05 19:13:43 @zmatt thank you ever so much Apr 05 19:13:47 :) Apr 05 19:13:48 this was driving me nuts Apr 05 19:14:05 today we learn, logs are useful Apr 05 19:14:41 @zmatt are you associated with BeagleBone or just doing volunteer support? Apr 05 19:15:11 I'm just a (professional) beaglebone user, I'm not affiliated with beagleboard.org Apr 05 19:15:48 well thanks so much - excited to get working on my project Apr 05 19:15:57 good luck! Apr 05 19:16:08 thanks Apr 05 19:16:10 :-) Apr 05 19:29:55 jkridner: rcn-ee[m]: would you be interested in supporting a new binary distro using the musl C-library and aiming for POSIX compliance? something a friend of mine is working on. A potential alternative to debian. Should be slicker and lower footprint .. Apr 05 19:30:21 how do you mean "supporting"? Apr 05 19:31:06 we can certainly inform people about it. Apr 05 19:31:57 jkridner: good question :D I know Rob has been doing much of the work with debian .. it seemed an interesting alternative. Of course I might have to ease the transition into 'support' as an intermediary initially, but the devs are very helpful :D Apr 05 19:31:57 veremitz: buildroot? Apr 05 19:32:07 rcn-ee[m]: nooo ... Adelie :) Apr 05 19:33:27 the path to release v1.0 is being a bit cumbersome because of certain web browsers development frameworks, but all the system stuff is pretty solid Apr 05 19:33:51 that said, KDE runs nicely on the Rpi3b :D *searches for the screenshot* (for comparison) Apr 05 19:39:46 boink->https://foxdotlife.files.wordpress.com/2019/02/screenshot_20190221_230557.png Apr 05 19:45:28 rcn-ee[m]: if I could figure out better how to use buildroot for some of my cross- woes.. I'd sure be a happy camper! :D Apr 05 19:45:57 I was thinking I needed to figure getting python3 and portage on a rootfs .. probably doable .. Apr 05 19:46:23 I need to build some new armv7 stage3 images though .. Apr 05 19:47:37 o/ awilfox Apr 05 19:47:45 hey veremitz Apr 05 19:48:22 all has gone quiet on the western front .. appears I killed the chat lol Apr 05 19:48:32 [fancy that..] ooh rhymeage Apr 05 19:50:41 jkridner: rcn-ee[m]: may I introduce you to the adelie lead-dev .. awilfox :) Apr 05 19:50:58 hi awilfox Apr 05 19:51:06 awilfox: I've been trying to extol the virtues of your distro :D lol Apr 05 19:52:00 I heard rumours that the debian support of arm is dwindling .. or at least some subarches .. Apr 05 19:52:15 I was trying ot pin down armv6 yesterday :/ lol Apr 05 19:52:52 hi jkridner :) Apr 05 19:59:49 * veremitz wonders how easy it would be to package the pru 'stuff' .. Apr 05 20:00:32 veremitz: rfc3 for mainline was posted again by roger, so maybe getting closer.. Apr 05 20:01:14 rcn-ee[m]: oh? Apr 05 20:01:18 there's ports of binutils/gcc for pru.. Apr 05 20:01:25 no way! Apr 05 20:01:26 or add the ti compiler/assember (it's built for 32bit arm) Apr 05 20:02:27 https://github.com/rogerq/linux/tree/for-v5.2/pruss-intc-3.0 Apr 05 20:02:37 https://github.com/rogerq/linux/tree/for-v5.2/pruss-soc-3.0 Apr 05 20:03:31 neat! Apr 05 20:05:21 rcn-ee[m]: that will be awesome to consolidate all the userspace stuff into something kernel-based Apr 05 20:06:36 it's always been kernel based.. uio_pruss is a kernel driver ;) Apr 05 20:06:45 well yes .. but .. :P Apr 05 20:06:59 we all know its had a chequered history :) Apr 05 20:09:11 I should catch up with project beagle .. its been a while .. Apr 05 20:13:00 I need to talk to Trinamics TMCM-6212 board using CAN. Any advice? Apr 05 20:14:48 talking can is pretty easy.... Apr 05 20:15:04 BeagleBone Blue has the CAN PHY built-in. Apr 05 20:15:20 you just need to add the termination resistors and do the wiring. Apr 05 20:16:58 Macchina has a PocketBeagle Cape with CAN and there is a BeagleBone Comms Cape with CAN (https://www.digikey.com/product-detail/en/ghi-electronics-llc/COMCPE-BBBCAPE/COMCPE-BBBCAPE-ND/8567318). Apr 05 20:18:34 veremitz: uio-pruss doesn't really have much "history"... it basically works the same all the way from 3.8 (or probably earlier even) to 4.19 :P Apr 05 20:19:31 zmatt: my memory is rusty :/ too much iron I guess .. I should upgrade to flash ;) Apr 05 20:19:56 veremitz: (unlike remoteproc-pru which, if I understand correctly, has seen incompatible changes with every major kernel version) Apr 05 20:20:07 ^ ah this is what I recall :P Apr 05 20:21:06 and I'm not sure if it even has basic functionality like shared memory mapping yet... last time I checked librobotcontrol ended up using /dev/mem because they felt the feed to switch from uio-pruss to remoteproc-pru Apr 05 20:21:16 which... is not a net improvement Apr 05 20:21:26 heh Apr 05 20:21:29 *felt the need Apr 05 20:21:42 * veremitz reads typo :) Apr 05 20:33:14 As far as CAN, I see an article BeagleBone CANBus & Python https://www.thomas-wedemeyer.de/beaglebone-canbus-python.html where it is suggested to use driver circuit SN65HVD231D from TI Apr 05 21:01:39 dreamhiker: there are probably tons of suitable CAN transceivers, if you want to make a custom hardware setup rather than using something prefab Apr 06 00:29:07 Do you think that the EXP430GS from TI will work w/ the BBB w/ the USB interface instead of connecting the connection directly from UART to UART? Apr 06 00:32:49 I was reading the info. from a couple of days ago (yesterday maybe) about connecting a TI MSP board to the BBB. Apr 06 00:32:50 ... Apr 06 00:33:14 The fellow was discussing USB connections instead of UART connections. Apr 06 00:34:53 Here: https://pastebin.com/8NTEqn12 is the software from BeagleBone Cookbook (Yoder, Kridner 2015). Apr 06 00:37:22 Also, in that book, there was a section on changing the serial.js and these are the lines: https://pastebin.com/vQP5XrWi. Apr 06 00:39:41 The first line of that last paste is the line I need to add to serial.js in /usr/local/lib/node_modules/bonescript/src/. Apr 06 00:39:52 Send rations! Apr 06 00:39:54 Please. Apr 06 00:41:16 the usb host interface of the bbb set_ ? yes probably Apr 06 00:41:19 if you put the right code on the TI Apr 06 00:41:24 Yes mawk. Apr 06 00:41:29 but you have to code it Apr 06 00:41:41 Right. I found the software in the book, too. Apr 06 00:41:44 using the usb ACM data communication class Apr 06 00:41:50 Oh. Apr 06 00:42:03 it's the virtual com port Apr 06 00:42:04 I need to find out more about that then. Apr 06 00:42:10 Oh. Okay. Apr 06 00:42:48 So, I program the EXPG2 from TI and program the BBB. Boom! It should work. I have some instructions. Apr 06 00:43:06 no you program the TI Apr 06 00:43:14 you don't need anything special on the bbb Apr 06 00:43:18 I will look up the ACM data communication class. Apr 06 00:43:20 Oh. Apr 06 00:43:27 google "CDC ACM" Apr 06 00:43:32 Alright. Apr 06 00:43:49 but a UART is easier to program for, on the TI Apr 06 00:43:52 way easier Apr 06 00:44:08 and you just need 3 standard prototyping cables instead of a usb cablez Apr 06 00:44:11 very easy Apr 06 00:44:14 I think this software was supposed to toggle some LEDs on the MSPEXPG2 from the communication of the BBB. Apr 06 00:44:42 All I saw in the schematic or photo was two uart leads. Apr 06 00:45:08 I will look up CDC ACM. Apr 06 00:48:24 So, it is just serial over USB. Apr 06 00:55:15 https://elixir.bootlin.com/linux/latest/source/drivers/usb/class/cdc-acm.c is something I found. Aw! Apr 06 00:55:16 ... Apr 06 00:55:31 but that's for linux Apr 06 00:55:33 Hey. Should I get this driver for the BBB? Apr 06 00:55:38 no Apr 06 00:55:39 Yes. Apr 06 00:55:40 it's in linux Apr 06 00:55:40 Oh. Apr 06 00:55:42 it's already in the kernel Apr 06 00:55:46 Oh. Apr 06 00:55:46 no need to install Apr 06 00:55:51 Okay. Apr 06 00:56:45 So, this type of connection is just for running the TI MSP board type off the BBB w/out programming the BBB? Apr 06 00:57:18 If that makes sense. Apr 06 00:57:43 I have energia for my TI Board. Apr 06 00:57:48 I am probably missing something. Apr 06 01:00:22 https://developer.ridgerun.com/wiki/index.php/How_to_use_USB_CDC_ACM_and_MS_composite_Linux_gadget_driver probably makes more sense, right? Apr 06 01:11:45 Hey? So, this CDC ACM idea just bypasses the BBB totally and runs commands already programmed on the /dev/ttyACM0 device? **** ENDING LOGGING AT Sat Apr 06 02:59:57 2019