**** BEGIN LOGGING AT Thu May 28 03:00:05 2020
May 28 03:00:50 <set_> It used to have a package from neurodebian but it is now outdated.
May 28 03:09:53 <set_> But...the psychopy will not work on the BBB. Dang.
May 28 03:10:00 <set_> Off to find a way.
May 28 03:33:40 <set_> Oh well. The psychopy people, I think, have not ported the library to python3.
May 28 03:33:41 <set_> Dang.
May 28 03:50:31 <set_> neurodebian works, though!
May 28 04:09:38 <set_> In the python2 docs. of psychopy, they have a section dedicated to eye tracking.
May 28 09:56:54 <Rucha> Hello Community, I am trying to configure hostapd file for 5GHz wifi band, but somehow can not configure to a/n/ac.
May 28 10:59:52 <set_> Hello, I am trying to make adafruit-BBIO work on the BBGW and I am trying to copy my requirements.txt file into a venv env.
May 28 11:00:07 <set_> I am getting errors b/c of rcpy.
May 28 11:00:21 <set_> My system cannot figure out why it is there or if it is used.
May 28 11:01:23 <zmatt> you're being waaaay too vague.  make a pastebin showing what you're doing (copy-paste a transcript of your terminal session including the errors you're getting in your face)  along with this requirements.txt
May 28 11:01:27 <set_> "No Matching Distribution found for rcpy==0.5.1.
May 28 11:01:35 <set_> Okay.
May 28 11:01:48 <zmatt> you're trying to use the roboticscape library on a BBGW ?
May 28 11:02:19 <set_> It just seems it is installed for some reason. I did not install it.
May 28 11:03:48 <zmatt> looks like rcpy 0.5.1 was never released: https://pypi.org/project/rcpy/#history
May 28 11:04:09 <zmatt> anyway, start by doing what I just said
May 28 11:04:30 <set_> https://pastebin.com/TjcX446j
May 28 11:04:40 <set_> Okay.
May 28 11:05:38 <zmatt> yeah I'm not surprised that doesn't work
May 28 11:06:53 <zmatt> I'm guessing there's some git version of rcpy installed (either by default or because you installed it yourself) and you're now trying to recreate that environment based on a requirements.txt file, which only works for packages that can be installed from pypi
May 28 11:07:14 <set_> Okay.
May 28 11:08:17 <zmatt> the unreleased rcpy you have installed is saying it's 0.5.1 (except it's not a released version thereof), so your requirements.txt (which you haven't shared yet) contains a request for "rcpy 0.5.1", and that's not installable since no such version of rcpy has ever been released to pipy
May 28 11:08:22 <zmatt> *pypi
May 28 11:08:36 <set_> Right.
May 28 11:08:40 <zmatt> so just remove that line from your requirements.txt
May 28 11:08:44 <set_> Okay.
May 28 11:08:51 <zmatt> why are you doing this exactly anyway?
May 28 11:09:20 <zmatt> you're trying to recreate your venv on the BBGW ?
May 28 11:09:27 <set_> I am making sure things work in a venv and system wide.
May 28 11:09:29 <zmatt> why not just copy the thing over?
May 28 11:09:35 <set_> I could.
May 28 11:09:37 <zmatt> why use a venv anyway?
May 28 11:10:14 <zmatt> also, iirc adafruit-bbio is already installed current images by default
May 28 11:10:25 <set_> Right...so.
May 28 11:10:28 <set_> This is why.
May 28 11:10:48 <set_> I cannot get the adafruit-bbio library to work in my venv for now.
May 28 11:11:00 <zmatt> why not?
May 28 11:11:08 <set_> I do not know.
May 28 11:11:38 <zmatt> what did you try?  what error are you getting?  share with pastebin
May 28 11:12:27 <set_> https://pastebin.com/TjcX446j
May 28 11:12:31 <zmatt> instead of trying to recreate everything you ever did in your venv (and who knows what that is), maybe you should actually examine the requirements.txt file (which you haven't shared yet) to see whether you actually have use for all that crap
May 28 11:12:43 <zmatt> yeah I explained why this doesn't work
May 28 11:12:45 <set_> Oh.
May 28 11:12:46 <set_> Okay.
May 28 11:12:50 <zmatt> but that has to do with rcpy, nothing with Adafruit_BBIO
May 28 11:12:57 <zmatt> you haven't tried to install that
May 28 11:13:22 <zmatt> (though you don't actually need to anyway since it's already installed on the system... though I don't know if that means it's also available in the venv)
May 28 11:13:41 <set_> Right. My rcpy version is installed system wide like Adafruit-BBIO.
May 28 11:13:51 <set_> It is not.
May 28 11:14:07 <set_> The venv makes it so I cannot use system wide resources.
May 28 11:14:21 <set_> It is another level of "secret" planning.
May 28 11:14:24 <set_> Ha.
May 28 11:14:27 <zmatt> I google python venv
May 28 11:14:30 <zmatt> click on the first link
May 28 11:14:36 <zmatt> https://docs.python.org/3/library/venv.html
May 28 11:14:57 <zmatt> and what do I see:   "--system-site-packages  Give the virtual environment access to the system site-packages dir."
May 28 11:15:07 <set_> https://pastebin.com/B0Sg5N5m
May 28 11:15:08 <set_> Oh.
May 28 11:15:12 <set_> Neat.
May 28 11:15:23 <zmatt> that's a huge list
May 28 11:15:46 <zmatt> you need all of this in your venv on the bbgw?
May 28 11:16:25 <set_> No. But, I can use some of them.
May 28 11:17:43 <set_> Is rcpy used by any other library for BBB related things or is it just for BBBlue stuff?
May 28 11:17:55 <zmatt> BBBlue or roboticscape
May 28 11:18:00 <set_> Okay.
May 28 11:22:24 <set_> If it ain't fix it, do not broke.
May 28 11:22:41 <zmatt> set_: https://pastebin.com/rXQHx3L7
May 28 11:23:10 <zmatt> there ya go, create a venv with --system-site-packages and you've fot Adafruit-BBIO and the magical rcpy 0.5.1 for free with no effort
May 28 11:23:16 <zmatt> *you've got
May 28 11:23:20 <set_> Okay.
May 28 11:23:25 <set_> I tried that just now.
May 28 11:23:31 <set_> I will test it real quickly.
May 28 11:24:00 <set_> Yep.
May 28 11:24:08 <set_> You got that right!
May 28 11:24:11 <set_> Nice.
May 28 11:24:30 <set_> I did not know that rcpy was still around.
May 28 11:24:56 <zmatt> ... is there a replacement?
May 28 11:25:05 <zmatt> oh right, it was kinda unmaintained
May 28 11:25:23 <zmatt> I guess someone's still keeping it alive, sorta :P  though not alive enough to submit it to pypi I guess
May 28 11:25:32 <zmatt> btw why are you using an absolute path to pip3 ?
May 28 11:25:39 <set_> Nice.
May 28 11:25:51 <set_> Oh.
May 28 11:26:29 <set_> When you say absolute path, I did b/c of the pip docs.
May 28 11:26:40 <set_> Let me see if I can find that page.
May 28 11:27:08 <set_> Here it is: https://pip.pypa.io/en/stable/reference/pip_freeze/#examples
May 28 11:34:28 <set_> One reason of this whole ordeal is this idea. I want to get scipy on my BBGW.
May 28 11:34:36 <set_> Sorry. scikit-learn.
May 28 11:35:01 <zmatt> ah you're indeed allowed to use a venv's pip like that... okay, didn't know
May 28 11:35:03 <set_> I got scipy on it to make the scikit-learn work. Now, I need to test to see if scikit-learn will install.
May 28 11:35:14 <zmatt> (haven't really used python venvs yet)
May 28 11:35:32 <set_> I started years ago but they came w/ so many "issues."
May 28 11:35:40 <set_> I just picked it up again.
May 28 11:36:17 <zmatt> sudo apt install python3-sklearn
May 28 11:36:18 <zmatt> ?
May 28 11:36:23 <set_> Yea.
May 28 11:36:32 <zmatt> or is that too optimistic?
May 28 11:36:40 <set_> But. it is outdated. I want to use their updated versions.
May 28 11:36:45 <set_> Ha.
May 28 11:36:47 <set_> I guess.
May 28 11:37:12 <set_> For instance, the scipy never worked on the BBGW w/ the older images.
May 28 11:37:25 <set_> Thus, I could never get scikit-learn to work.
May 28 11:37:45 <set_> It might have been me but I could not never get it to work.
May 28 11:39:54 <zmatt> looks like debian stable (buster) has v0.20.2 while debian testing (bullseye) and unstable (sid) have v0.22.2
May 28 11:40:02 <set_> Hmm.
May 28 11:40:06 <set_> Let me check my version.
May 28 11:40:20 <set_> 0.23.1.
May 28 11:40:26 <set_> I guess that is not so old.
May 28 11:40:35 <set_> It worked!
May 28 11:40:59 <set_> Now, onto brighter headaches!
May 28 11:41:01 <zmatt> so yeah, v0.20.2 is a bit dated (2018-12-19), v0.22.2 is pretty recent (2020-02-28)
May 28 11:41:13 <set_> Hmm. I have buster on my machine.
May 28 11:41:18 <zmatt> you installed 0.23.1 using pip I guess?
May 28 11:41:22 <set_> Yes.
May 28 11:41:31 <zmatt> well, there ya go :)
May 28 11:41:58 <set_> Nice. The issue w/ the pip3 install was that scipy would never fully install w/ pip3.
May 28 11:42:16 <set_> Thus, I could not get the scikit-learn to install on the machines.
May 28 11:42:34 <zmatt> but now you're using --system-site-packages so your venv has access to the scipy that's already installed on the system
May 28 11:42:36 <set_> scipy is a dep. of scikit-learn.
May 28 11:42:56 <set_> Right, sort of. I had scipy in that venv already.
May 28 11:43:26 <set_> But, b/c of you, I now know what exactly --system-site-packages does.
May 28 11:43:54 <set_> I used it like so: python3 -m venv Mort --system-site-packages.
May 28 11:45:38 <set_> Then, I had to use pip3 freeze > requirements.txt.
May 28 11:46:00 <set_> That put all my python3 modules in the requirements.txt.
May 28 11:46:29 <zmatt> well you don't "have to use", it's just a convenience to get a list of everything that's installed in one place so you can (hopefully, not always as the rcpy incident shows) install it in another place
May 28 11:47:19 <set_> Right or if you want to make something that works w/ current versioning work again, just install requirements.txt in a new location.
May 28 11:48:01 <zmatt> beware though, the requirements.txt created by pip3 freeze uses exact version matches (==)
May 28 11:48:19 <zmatt> so it will even downgrade packages to get things exactly the same as they were on your previous system
May 28 11:48:26 <set_> Right. I thought that was the reasoning for using it.
May 28 11:48:27 <set_> Oh.
May 28 11:48:54 <set_> The exact versioning is why I wanted to use it.
May 28 11:49:21 <zmatt> why is that desirable?  generally it's a good idea to use the latest versions of things
May 28 11:49:57 <set_> For instance, if I find that version==1.9.2 does not work but version==1.8.2 did, I can then revert back.
May 28 11:50:35 <set_> Sometimes, things work and sometimes things do not work. This is esp. true in versioning from what I can tell.
May 28 11:50:57 <set_> It is odd. Some people update while others just stop (for whatever reason).
May 28 11:51:26 <zmatt> fair enough, but then you should probably just manually keep a requirements.txt containing the packages you want and your version requirements on them
May 28 11:51:37 <set_> For instance, the Replicape people had a main contributor stop. Things got put on hold. I think that person eventually came back.
May 28 11:51:47 <zmatt> and if you're a smart cookie, you'll add some comments to reminder yourself later _why_ you needed the packages or why you needed specific versions
May 28 11:51:54 <zmatt> *to remind yourself
May 28 11:51:56 <set_> Right!
May 28 11:52:10 <set_> I am still working on the whole comments '#' thing.
May 28 11:52:23 <set_> It is a task in itself.
May 28 11:52:37 <set_> What, why, how?
May 28 11:52:43 <set_> Ha.
May 28 11:53:35 <set_> I have been trying to use different libraries from python3 to prove GenTooMan wrong but I think he was right.
May 28 11:54:14 <set_> Digital Video needs to be stopped in order to process so it can then be dubbed/changed.
May 28 11:55:33 <set_> I thought I could process what was stopped aside from an ongoing video clip being recorded. Nope.
May 28 12:40:41 <zmatt> oh nice, Adafruit_BBIO fails to compile with the current images because they use -Werror and the gcc 8.3 on the new images had added a bunch of a new warnings
May 28 12:43:47 <GenTooMan> zmatt that's a tough one, -Werror is a convenience option only. Checking for version information is probably advisable when doing something like that.
May 28 12:48:47 <zmatt> use -Werror for internal projects and during development
May 28 12:49:05 <zmatt> don't ship source code with -Werror enabled by default to users
May 28 12:49:18 <zmatt> since it'll mean your project will randomly break depending on compiler version
May 28 12:50:30 <zmatt> oh nice, Adafruit_BBIO apparently got warnings for strict aliasing violations.. so instead of fixing those or using -fno-strict-aliasing to simply not have to worry about it anymore, they just used -Wno-strict-aliasing to suppress the warnings
May 28 12:50:45 <mru> idiots
May 28 13:04:13 <zmatt> weird, according to the distutils source code flags from the CFLAGS environment variable are supposed to be appended at the end to ensure they override everything... but when I try it they actually end up super early in the gcc invocation
May 28 13:53:09 <MattB0ne> OK got a small problem
May 28 13:53:39 <MattB0ne> I am trying to move my verified serial connection to move through the BBB
May 28 13:53:54 <MattB0ne> i am going through the MAX3232 which is working until the device
May 28 13:54:12 <MattB0ne> the MAX3232 is powered by the 3.3V pin
May 28 13:54:43 <MattB0ne> the MAX does not allow me to have the GND pin connected on from the device
May 28 13:54:50 <MattB0ne> since the power is supplied by the BBB
May 28 13:54:59 <MattB0ne> it seems I need that GND.
May 28 13:55:20 <MattB0ne> I tried connecting with out it and the serial breaks when I was communicating via RS232
May 28 13:55:36 <MattB0ne> when I try to go through the MAX I cannot wire the GND pin so it does not work
May 28 13:56:13 <MattB0ne> how can I power the MAX3232 by the BBB while having a GND pin connected from the device
May 28 13:56:25 <mru> why can't you connect the gnd pin?
May 28 13:56:48 <MattB0ne> because I am powering from the BBB and the PSU pins are connected
May 28 13:56:58 <MattB0ne> like I could not power the board from both sides right ?
May 28 13:57:11 * mru must be missing something
May 28 13:57:11 <MattB0ne> power the MAX3232
May 28 13:57:14 <MattB0ne> lol
May 28 13:57:25 <MattB0ne> I am not too clear
May 28 13:57:35 <MattB0ne> barely understand the MAX2322
May 28 13:57:50 <MattB0ne> but I have 4 slots on each side of it
May 28 13:57:57 <MattB0ne> 1 for the TTL other for the serial
May 28 13:58:10 <MattB0ne> 2 of the slots are for coms Tx and Rx
May 28 13:58:20 <MattB0ne> the other is + and - for the PSU
May 28 13:59:20 <MattB0ne> on the TTL side I have all 4 wired up
May 28 13:59:29 <MattB0ne> to protect the BBB due to the 3.3V level logic
May 28 13:59:36 <MattB0ne> on the serial side I have the COMS wired
May 28 13:59:43 <MattB0ne> but I leave the PSU blank
May 28 13:59:47 <mru> which IC are you using?
May 28 14:00:01 <mru> you've mentioned several MAXxxxx numbers
May 28 14:00:22 <MattB0ne> i am not sure
May 28 14:00:27 <MattB0ne> UART
May 28 14:00:31 <mru> what does it say on the chip?
May 28 14:01:15 <MattB0ne> not much on the chip
May 28 14:01:23 <MattB0ne> RS232<->TTL
May 28 14:01:31 <MattB0ne> HW027
May 28 14:01:34 <mru> does the chip not have a part number?
May 28 14:01:44 <mru> you said MAX3232
May 28 14:01:48 <MattB0ne> yeah
May 28 14:01:49 <mru> then you said MAX2322
May 28 14:01:55 <MattB0ne> that is what I bought
May 28 14:01:59 <mru> that latter one is something completely different though
May 28 14:02:05 <mru> what did you buy?
May 28 14:02:15 <mru> do you have a link to the product you bought?
May 28 14:04:46 <zmatt> he's using a max3232 breakout
May 28 14:04:58 <zmatt> a very cheap breakout with no schematic or datasheet :P
May 28 14:05:08 <MattB0ne> max3232
May 28 14:05:14 <mru> well, how are we supposed to help with that?
May 28 14:05:20 <MattB0ne> lol
May 28 14:05:27 <mru> do you have a picture of the thing?
May 28 14:05:30 <MattB0ne> sure
May 28 14:05:57 <zmatt> MattB0ne: note that the PSU connections on both sides are just tied together, according to the description anyway
May 28 14:06:18 <zmatt> they probably did that to make it easier to accidently use it the wrong way around
May 28 14:06:37 <MattB0ne> anyway I can incorporate a GND in my connection to the device
May 28 14:06:54 <zmatt> "incorporate a GND" ?
May 28 14:06:55 <MattB0ne> it appears to be necessary to work but I cannot incorporate with the MAX3232
May 28 14:07:01 <zmatt> ?????
May 28 14:07:05 <zmatt> GND is absolutely required
May 28 14:07:07 <MattB0ne> in the schematic for connection via RS232
May 28 14:07:15 <MattB0ne> I need the Tx, Rx and GND
May 28 14:07:27 <MattB0ne> but the Max allows for just a Tx and Rx
May 28 14:07:28 <mru> teh max3232 chip has one gnd and one vcc pin
May 28 14:07:29 <zmatt> on right, that's one reason for the PSU pass-through
May 28 14:07:37 <zmatt> you can use the ground pin on the other side
May 28 14:07:40 <MattB0ne> ok
May 28 14:07:41 <zmatt> (the "-")
May 28 14:07:47 <MattB0ne> ok phew
May 28 14:07:48 <zmatt> (which is a very awful way to label a ground)
May 28 14:07:52 <MattB0ne> let me solder
May 28 14:07:55 <MattB0ne> see how it goes
May 28 14:08:18 <zmatt> MattB0ne: I'd suggest measuring the voltage on the I/O pins before connecting it to the BBB
May 28 14:08:49 <zmatt> since if you "see how it goes" with the wrong pins connected to the BBB, that may the last thing your BBB will see
May 28 14:10:12 <mru> the max3232 runs off a 3-5V supply and uses charge pumps to create the rs232 levels
May 28 14:10:17 <zmatt> you could also spend $6 on the sparkfun max3232 breakout that allows you to solder on header for easy jumpering, has a schematic, and has very clear labeling
May 28 14:11:14 <zmatt> mru: I think this was the one he has: http://www.hiletgo.com/ProductDetail/3433372.html
May 28 14:12:13 <mru> how do people even find such crap?
May 28 14:13:03 <zmatt> I have no idea
May 28 14:13:18 <mru> and I don't mean just this thing
May 28 14:13:54 <Ragnorok> Lack of experience searching for usable items?
May 28 14:14:42 <Ragnorok> I have some things that fall into that category, and now I have more experience at it.  (shrug)
May 28 14:15:41 <zmatt> the one I found was: https://www.sparkfun.com/products/11189 ... the only complaint I have at first glance is that the photography sucks, on the first three photos it looks like it has surface-pads for your connection, while they're actually holes for a header but the lighting manages to conceal those complete... the last photo with a coin as backdrop finally makes the holes visible ;)
May 28 14:28:50 <mru> it also wouldn't be difficult to make your own
May 28 14:29:11 <mru> with a pin header suitable to plug directly into the beagle
May 28 14:34:04 <MattB0ne> may need to make my own
May 28 14:34:30 <MattB0ne> soldered the ground to the MAX and still cannot communicate
May 28 14:34:42 <MattB0ne> I am going to try and check the pins
May 28 14:34:49 <MattB0ne> volatage
May 28 14:36:35 <MattB0ne> this is a kick in the ballz
May 28 14:36:43 <MattB0ne> I thought I was over the hump
May 28 14:36:59 <mru> did you have it working from a PC?
May 28 14:37:02 <MattB0ne> yeah
May 28 14:37:14 <mru> can you connect the PC to the beagle?
May 28 14:37:29 <MattB0ne> yeah that is how I am testing
May 28 14:38:50 <MattB0ne> ssh to beagle
May 28 14:38:52 <MattB0ne> and send commands
May 28 14:40:03 <MattB0ne> path of least resistance is to get this
May 28 14:40:03 <MattB0ne> https://www.amazon.com/DEVMO-Connector-Converter-Equipment-Upgrades/dp/B07Y88QXN4/ref=sr_1_1_sspa?dchild=1&keywords=max3232&qid=1590676776&sr=8-1-spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUExOFZNS05aWkNaT1RJJmVuY3J5cHRlZElkPUEwMjc4MzgyM0NBTjdCWE5QUktHNiZlbmNyeXB0ZWRBZElkPUEwNDc3MTQwMUxTQ1k3WDFZWkY1RSZ3aWRnZXROYW1lPXNwX2F0ZiZhY3Rpb249Y2xpY2tSZWRpcmV
May 28 14:40:04 <MattB0ne> jdCZkb05vdExvZ0NsaWNrPXRydWU=
May 28 14:40:08 <MattB0ne> has the port
May 28 14:41:16 <mru> you can trim off all that crap from the amazon link, you know
May 28 14:41:28 <mru> everything after the product code (B07Y88QXN4)
May 28 14:42:00 <MattB0ne> did not know that
May 28 14:42:21 <mru> the rest is just tracking junk
May 28 14:43:53 <GenTooMan> that's what they said with satellites...
May 28 14:59:37 <zmatt> MattB0ne: have you done any sort of loopback testing with that max3232 breakout?
May 28 15:01:26 <zmatt> since it's so poorly documented you should really focus on making sure you know what's what on this thing.  you might be able to simply examine the pcb to trace what pin of the max3232 goes where, you can measure voltages to hopefully identify what's rs232 and what's 3.3V serial
May 28 15:01:43 <zmatt> there's all sorts of ways you could test the max3232 board standalone
May 28 15:04:31 <mru> I doubt it's a multi-layer board so tracing the signals should be easy
May 28 15:09:31 <MattB0ne> I have tested the Max3232 pretty extensively
May 28 15:09:44 <MattB0ne> done loop back and what not
May 28 15:10:50 <zmatt> how exactly, if you didn't even have a ground connection?
May 28 15:11:01 <zmatt> or at least, were confused about how to connect ground
May 28 15:11:09 <zmatt> (which is not a good sign)
May 28 15:11:16 <mru> the loopback would still work
May 28 15:11:35 <zmatt> if you connect only txd and rxd?  seems unlikely
May 28 15:11:49 <MattB0ne> the loopback worked in both instances
May 28 15:11:51 <zmatt> but it depends on how exactly you wired it up
May 28 15:11:57 <mru> connecting tx to rx would send the data back to yourself
May 28 15:11:58 <mru> isn't that what loopback means?
May 28 15:12:30 <zmatt> mru: yeah but you'd do a loopback on one side of the max3232, the other side still needs to connect to something, and that needs to include ground
May 28 15:13:12 <mru> I was thinking the loopback test would be done without the remote thing connected
May 28 15:13:22 <mru> just to validate the connection between the beagle and the max3232
May 28 15:13:38 <mru> what did I misunderstand this time?
May 28 15:13:47 <zmatt> depends on what kind of loopback test
May 28 15:13:56 <zmatt> you can perform a loopback test on either side of the max3232
May 28 15:14:21 <mru> sure, and neither would require you to connect anything to the ground pin
May 28 15:14:36 <mru> I'm assuming gnd and vcc were connected to the beagle all along
May 28 15:14:48 <mru> maybe I'm assuming too much
May 28 15:14:59 <zmatt> yeah true, fair
May 28 15:15:02 <zmatt> for power
May 28 15:15:49 <zmatt> but you could still do a loopback test with txd->rxd on the low voltage side and the RS232 side connected to a PC
May 28 15:15:55 <zmatt> while powered from the BBB
May 28 15:17:20 <zmatt> MattB0ne: anyway, make sure everything is properly grounded together at all times, you absolutely need that (and broken ground connection can cause damage, depending on the circumstances)
May 28 15:19:09 <MattB0ne> ok
May 28 15:21:14 <MattB0ne> when you say grounded together
May 28 15:21:25 <MattB0ne> what do you mean
May 28 15:21:37 <MattB0ne> I am using two grounds one on the device and one on the BBB
May 28 15:22:24 <zmatt> BBB ground, max3232 ground, device ground, they should all be the same net (i.e. connected together, directly or indirectly)
May 28 15:22:36 <MattB0ne> ok I am not doing that
May 28 15:22:40 <MattB0ne> I need to
May 28 15:22:44 <zmatt> ??
May 28 15:22:50 <zmatt> how did you connect it?
May 28 15:23:02 <MattB0ne> i am using GNDC from the device on the Serial side
May 28 15:23:12 <MattB0ne> and the BBB GND on the TTL side
May 28 15:23:14 <zmatt> connected to
May 28 15:23:15 <zmatt> ?
May 28 15:23:32 <MattB0ne> GNDC to Serial -
May 28 15:23:39 <MattB0ne> GND BBB to TTL -
May 28 15:23:45 <MattB0ne> nothing really joining them
May 28 15:23:48 <zmatt> that's the same thing, there's no "Serial -" / "TTL -"
May 28 15:23:51 <zmatt> there's just ground
May 28 15:23:55 <zmatt> the max3232 has only one ground
May 28 15:24:21 <MattB0ne> which is the "-"
May 28 15:24:31 <MattB0ne> so I have two ports for it then
May 28 15:24:42 <zmatt> like I said last time (more than once) and said quite recently today: the two power supply connections on your weird little breakout are, according to the webpage, simply connected together
May 28 15:24:53 <MattB0ne> right
May 28 15:25:01 <MattB0ne> but I need the 3.3V from the BBB
May 28 15:25:02 <zmatt> there's also nothing else it could possibly do since the max3232 has one ground pin and one supply pin
May 28 15:25:09 <MattB0ne> so I used both the 3.3V and GND from the BBB
May 28 15:25:15 <zmatt> yes
May 28 15:25:20 <MattB0ne> but that does not work
May 28 15:25:22 <zmatt> GND is GND (for everyone)
May 28 15:25:28 <zmatt> 3.3V from BBB is the supply for the max3232
May 28 15:25:33 <MattB0ne> right
May 28 15:26:00 <zmatt> you have a multimeter?  to test continuity?
May 28 15:26:30 <MattB0ne> yes I can do that
May 28 15:27:38 <zmatt> with the BBB <-> max3232 <-> EM-100 connection in place (to the best of your ability/understanding), but nothing else connected (no USB, no power)
May 28 15:28:00 <zmatt> set multimeter to measure continuity (with beeeep)
May 28 15:28:10 <zmatt> stick one end in a random GND pin of the BBB
May 28 15:28:47 <zmatt> confirm it beeps on the MAX3232 breakout's "-" pins (both of them) and therefore also on the EM-100 GND
May 28 15:30:11 <zmatt> you could also just test the max3232 breakout by itself: confirm the two "-" pins are in fact connected together, likewise for the two "+" pins
May 28 15:34:26 <MattB0ne> they are
May 28 15:34:53 <MattB0ne> maybe I use the + from the BBB and the - from the device
May 28 15:35:10 <zmatt> so if one "-" pin connects to BBB GND and the other "-" connects to EM-100 GNDC then that means all grounds are connected together, as they're required to be
May 28 15:35:21 <MattB0ne> ok
May 28 15:35:30 <MattB0ne> let me plug that in
May 28 15:37:16 <zmatt> I cannot emphasize this enough:  everything here _needs_ to have the same gound.  the ground of the BBB, the ground of the max3232, the (signal-)ground of the EM-100, they _MUST_ be connected in some way or another
May 28 15:37:34 <zmatt> since all voltages are defined relative to GND
May 28 15:37:51 <zmatt> if there's no agreement on what GND is, then there's no agreement on what any voltages are
May 28 15:38:07 <zmatt> nothing will work, smoke may be released
May 28 15:39:47 <zmatt> anyway, go analyze stuff, go measure stuff.  think about what's supposed to happen and how you can confirm that it is happened and if not, where things are going wrong
May 28 15:40:10 <zmatt> here's a summary of how the max3232 behaves, for reference: https://pastebin.com/bCiDrVCf
May 28 15:41:15 <zmatt> (note that the max3232 has two drivers and two receivers, but presumably your breakout only lets you use one of them?)
May 28 15:41:29 <zmatt> anyway, I got stuff to do
May 28 15:41:49 <MattB0ne> yeah I will read up a bit
May 28 15:42:04 <MattB0ne> basically at some point the gnds need to come together
May 28 15:42:09 <MattB0ne> a global ground
May 28 15:42:16 <MattB0ne> I do not have that
May 28 15:42:40 <MattB0ne> though when hooked up to my PC
May 28 15:42:54 <MattB0ne> my PC i guess dictated it
May 28 15:43:05 <MattB0ne> whatever need a break
May 28 15:46:42 <mru> global ground, unless you're a flat earther, then you need a ground plane
May 28 15:53:59 <zmatt> MattB0ne: it's starting to get really annoying to have to keep repeating this:  the whole point of the exercise I just had you do what to show that you _DO_ have a common ground.  at least you do for how I interpret what you described, as well as any even remotely sane way of wiring things up
May 28 15:54:52 <zmatt> unless you stuck a wire into a flowerpot with some earth in it and said "there, now it's grounded"
May 28 15:55:12 <mru> (audiophools do more or less that)
May 28 15:58:26 * GenTooMan tries not to shake his head so he doesn't feel it rattle.
May 28 16:01:31 <zmatt> anyway, I'm off
May 28 16:44:33 <MattB0ne> lol
May 28 16:47:15 <MattB0ne> thanks for the help zmatt
May 28 17:04:04 <veremitz> zmatt: that's not grounded - that's Earth'd :P
May 28 17:04:12 <veremitz> *groan*
May 28 17:13:49 <kremlin> m
May 28 18:01:32 <GenTooMan> m2u k
May 28 19:43:17 <thinkfat> can a dmtimer do capture and pwm at the same time?
May 28 19:45:41 <thinkfat> looks like...
May 28 19:45:50 <thinkfat> that could be convenient
May 28 19:47:07 <thinkfat> I'm looking for a way to produce a smoothed 1pps output with less jitter than what is available from the GPS timesignal...
May 28 19:57:45 <thinkfat> so, since the OCXO clock drives tclkin, I could program TMAR to always advance 10e6 counts when a match occurs, creating a "virtual" 1pps source. This would then output a trigger pulse on the PWM output...
May 28 20:00:48 <thinkfat> moreover, since the capture input of the timer is connected to the GPS timesignal, I could use that difference to phase-align the OCXO so that virtual and the actual pps signal clock in at the same time...
May 28 20:01:26 <thinkfat> hmmmm
May 28 20:08:01 <bbai_help> How do I get SPI working on a beaglebone ai?
May 28 20:11:34 <bbai_help> So far, I copied am5729-beagleboneai-roboticscape.dtb into am5729-beagleboneai.dtb
May 28 20:12:21 <bbai_help> I see a spidev1.0, and spidev1.1 in the /dev folder.
May 28 20:14:02 <bbai_help> Any read so far on spidev1.0 is just 0's. I am using P9_17 (cs), P9_18 (mosi), P9_21 (miso), P9_22 (sclk)(
May 28 20:14:52 <bbai_help> Compared to normal bbb, the mosi/miso have swapped. I tried switching those pins too to no effect
May 28 20:16:28 <bbai_help> using latest 10.3 build of Debian on bbai
May 28 20:20:02 <thinkfat> nope, useless.
May 28 20:20:56 <thinkfat> the pwm output will always pulse or trigger on internal overflow :-( No way to just emit a pulse when a match occurs
May 28 20:21:29 <mru> how much jitter is there in the pps signal, and much do you want it reduced?
May 28 20:34:53 <thinkfat> mru: some 10ns or so, it depends a bit on the internal clock of the GPS receiver
May 28 20:35:22 <mru> is 10 ns the jitter from the gps?
May 28 20:35:48 <thinkfat> mru: thing is, the timepulse output is always synchronous to the internal clock, so obviously there is a quantization error
May 28 20:36:11 <mru> yes, but what do do you have and what do you need?
May 28 20:36:17 <mru> I can't read your mind
May 28 20:37:00 <thinkfat> I actually want two things: a 1PPS output that has less jitter than what the GPS can deliver,
May 28 20:37:12 <mru> right, but how much jitter can you tolerate?
May 28 20:37:48 <thinkfat> 1ns is certainly in reach...
May 28 20:38:08 <mru> how can you now know what you want?
May 28 20:38:14 <mru> or need, rather
May 28 20:38:16 <thinkfat> it's not about what is tolerable but what can be achieved
May 28 20:38:34 <mru> start with a wish list
May 28 20:38:44 <mru> and don't say zero
May 28 20:38:52 <thinkfat> the second thing is, I want pps events for timekeeping even without GPS, for the holdover case
May 28 20:39:23 <thinkfat> I think I can achieve that with the compare mode
May 28 20:41:12 <mru> there are nice ICs for exactly this purpose
May 28 20:41:21 <mru> here's one: https://www.ti.com/product/LMK05318
May 28 20:50:26 <mru> using counters and timers you'll be limited by the resolution of their clock
May 28 20:57:10 <thinkfat> maybe, but I have a 56ps resolution interpolator that can do the fine tuning, so I need the timers only for the coarse stuff
May 28 20:59:05 <thinkfat> on the timer side I can live with 100ns resolution easily, the idea is to phase-lock the 10MHz ocxo clock to the time signal from the GPS as closely as possible. Then, every timer event will be syncronous to the GPS time.
May 28 21:01:27 <mru> what's this interpolator?
May 28 21:01:33 <thinkfat> TDC7200
May 28 21:02:22 <mru> what's the context of all this?
May 28 21:02:36 <thinkfat> a gpsdo that doubles as a ptp / ntp server
May 28 21:05:31 <mru> so you have a gps with pps output?
May 28 21:06:14 <thinkfat> yep, I've integrated a ublox m8t module
May 28 21:06:35 <mru> and this pps output has more jitter than you like?
May 28 21:07:42 <thinkfat> definitely ;)
May 28 21:07:53 <mru> how much, roughly?
May 28 21:08:24 <thinkfat> +/- 5ns or so
May 28 21:08:43 <thinkfat> after quantization correction.
May 28 21:08:59 <thinkfat> the raw time signal has maybe +/- 20ns
May 28 21:08:59 <mru> how does this tdc7200 fit in?
May 28 21:09:38 <thinkfat> it measures the time from the 1PPS gps time pulse to an arbitrary edge of a 10MHz clock
May 28 21:10:21 <mru> can you vary the 10 MHz clock?
May 28 21:10:39 <thinkfat> well, precisely, to an arbitrary edge of a 500kHz clock that is divided-down from the 10MHz clock
May 28 21:11:08 <thinkfat> yep, that's the whole idea
May 28 21:11:30 <thinkfat> I pull and push the 10MHz clock until it's phase-locked to the 1PPS
May 28 21:11:55 <mru> so it's a vcxo of some sort?
May 28 21:12:17 <thinkfat> yes, OCXO. A VCXO in a heated enclosure
May 28 21:12:36 <mru> and how do you generate the control voltage?
May 28 21:13:22 <thinkfat> a dac. let me check which one I use
May 28 21:14:01 <mru> why don't you just use an off the shelf jitter cleaner?
May 28 21:15:09 <ds2> there are units that will do everything
May 28 21:15:16 <ds2> they're used for telco clocks
May 28 21:15:20 <mru> like the one I linked above
May 28 21:15:28 <mru> a bit overkill for this application, perhaps
May 28 21:16:00 <mru> other devices are available from ADI, silabs, IDT, ...
May 28 21:16:15 <mru> hell, microchip probably has something
May 28 21:16:19 <ds2> not chips, modules with GPS and everything
May 28 21:18:43 <thinkfat> heh, that LMK chip is not cheap...
May 28 21:19:54 <ds2> those modules show up cheap on ebay
May 28 21:20:22 <thinkfat> and the phase noise is only -70dBc@1Hz...
May 28 21:21:12 <thinkfat> so, that what does that give me, 10MHz right?
May 28 21:21:22 <thinkfat> or, whatever I program it to deliver
May 28 21:21:46 <ds2> think 10MHz is standard
May 28 21:21:58 <mru> that chip can output just about anything
May 28 21:21:59 <ds2> GPS by itself is jittery so you phase lock that to a LO
May 28 21:22:23 <thinkfat> that's precisely what a gpsdo does ;)
May 28 21:23:03 <ds2> yes, it is physics
May 28 21:23:58 <thinkfat> but still - what happens if the time signal from the GPS goes away because of bad coverage?
May 28 21:24:30 <mru> you get a free-running oscillator
May 28 21:24:34 <ds2> it should maintain it with a random drift over time
May 28 21:24:57 <ds2> if you get a good OCXO, that should be a while
May 28 21:25:13 <ds2> or get a local atomic OX
May 28 21:25:49 <thinkfat> that I have already... the gpsdo I'm now making for the BBB is a spin-off of a Rb-GPSDO I did before...
May 28 21:26:12 <ds2> then you must know all this already :D
May 28 21:26:24 <thinkfat> yes, I've been leading you on all the time :-D
May 28 21:26:43 <thinkfat> honestly, I have no idea about these clock synchronizers
May 28 21:27:02 <thinkfat> I know of a commercial gpsdo that uses one, guy named Leo Bodnar sells them
May 28 21:27:14 <ds2> those new or used?
May 28 21:27:24 <thinkfat> new, his own design
May 28 21:27:51 <thinkfat> leobodnar.com
May 28 22:41:36 <zmatt> zeml
May 28 22:41:40 <zmatt> whoops
May 28 22:41:57 <mru> you really should use longer passwords
May 28 23:10:05 <thinkfat> note to self: if you cannot figure out how to subtract unsigned ints, its time to sleep
May 28 23:10:59 <set_> Thank you.
May 28 23:11:27 <set_> Ha.
May 28 23:57:10 <set_> heh?
May 28 23:58:00 <set_> Fine. YOu are right. There is not time to act childish. Please forgive me.
May 28 23:58:25 <set_> "No extremes, just no childish stuff. Got it"
May 28 23:58:57 <mru> are you talking to yourself, or am I seeing only half a conversation?
May 29 00:07:20 <set_> I am chatting w/ myself as usual.
May 29 00:07:30 <set_> I am a brian.
May 29 00:07:33 <set_> Ha.
May 29 00:21:52 <set_> I know this is an old habit but I am learning right now how to make cat .gif files on my BBB.
May 29 00:22:20 <set_> Send them w/ xoxo? <<< I still do not know what that means.
May 29 00:23:55 <set_> I am messing w/ imageio on the BBB (NEON).
May 29 00:31:54 <set_> GenTooMan: Look here! I think I may have unEarthed a creator that makes frames of video: https://imageio.readthedocs.io/en/stable/examples.html#grab-frames-from-your-webcam.
May 29 00:41:56 <set_> SOunds to good to be true...it is. Nothing is python3 compatible. Blah.
May 29 00:42:12 <set_> Well, not 3.7.
May 29 00:51:29 <set_> I just received this error: Memory Error.
May 29 00:51:41 <set_> Is there a way around this issue?
May 29 00:57:33 <set_> I was installing wxpython and the memory error came up. First time!
May 29 01:32:32 <set_> Hello, are there any backends that work w/ the BBB?
**** ENDING LOGGING AT Fri May 29 02:59:57 2020