00:00 <_whitenotifier-f> [glasgow] attie commented on pull request #238: init kicad-exports to run on all 'wip-revC[0-9]' branches - https://git.io/JIYYR

00:14 <_whitenotifier-f> [glasgow] whitequark commented on pull request #238: init kicad-exports to run on all 'wip-revC[0-9]' branches - https://git.io/JIYOp

01:14 <_whitenotifier-f> [glasgow] Success. The Travis CI build passed - https://travis-ci.org/github/GlasgowEmbedded/glasgow/builds/747520312?utm_source=github_status&utm_medium=notification

01:28 <d1b2> <icb> 3300ppm CO₂ is quite high. Either that reading is wrong, or you need to take a good look at better ventilation

01:28 <whitequark> 3300 ppm sounds like they exhaled in excitement right at the sensor

01:28 <d1b2> <icb> That's possible too

01:28 <whitequark> happens often to me

01:33 <d1b2> <0x53A> Jup the sensor was directly in front of me on the table. Thank you for your concern :D (and I did vent afterwards) Though that is actually my goal with this sensor: to build a co2 monitor so I don't forget to open the window now and then, especially now in winter when I can't keep it open.

01:34 <whitequark> just don't publish the high-resolution sensor data

01:35 <whitequark> because it gives away your sleep, activity, movement...

01:35 <whitequark> not a safety concern for most people but a privacy issue nevertheless

01:35 <d1b2> <icb> Good to hear. I have to keep my windows open in winter or the temperature gets unbearably hot. My apartment building uses steam heat, and it's not well maintained

01:41 <d1b2> <0x53A> Yeah I've seen your tweets a year? ago. Technically, it's really amazing, same with acceleration sensors. My goal is to build the same thing you did and push it to this time series database thing, I'd password protect it obviously.

01:42 <whitequark> influxdb? yeah

01:43 <d1b2> <Attie> i received my SCD30s today, and set mine up too... for similar reasons

01:43 <d1b2> <Attie> https://cdn.discordapp.com/attachments/613461005392936961/784233389895974972/unknown.png

01:44 <d1b2> <0x53A> Just out of curiosity, do you know what your "favorite" temperature is? The sensor was saying 25°, but it felt too cold in a T-shirt. Though I'm almost always a bit frosty compared to others ...

02:07 <d1b2> <Attie> i like ~19-21'C

02:07 <d1b2> <Attie> much more is "too hot"

02:08 <whitequark> it varies a lot between people

02:08 <whitequark> and it can change greatly because of such reasons as "different hormonal profile", beyond all the usual suspects

11:02 <electronic_eel> @Attie since you are building the can addon and plan to write can gateware i thought this might be interesting for you. i just stumbeled upon this link: https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core

11:03 <electronic_eel> @Attie it is a ip core for canfd. unfortunately it is in vhdl. but maybe it can serve as inspiration

11:05 <electronic_eel> can fd is of course much more complex that plain old can

13:58 <d1b2> <Attie> @electronic_eel thanks for the link!

13:59 <d1b2> <Attie> I certainly didn't want to preclude CAN-FD in hardware, but my initial goal is plain-old-CAN

17:16 <d1b2> <Attie> I'm considering licenses for the Glasgow CAN project (hardware + software)... I don't want to preclude rolling it into the main repo / an "official" add-on repo some day

17:16 <d1b2> <Attie> are 0-clause BSD and Apache 2.0 suitable for the hardware side of things?

17:17 <d1b2> <Attie> (I also spotted what is likely a mistake in LICENSE-Apache-2.0.txt... does it need a fix? - https://github.com/GlasgowEmbedded/glasgow/blob/master/LICENSE-Apache-2.0.txt#L189)

17:17 <d1b2> <Attie> oh, hah... my reading is on form today! ignore the "mistake" comment

17:58 <electronic_eel> @Attie the whole glasgow repo, including the hardware files, is 0-BSD and Apache-2.0. so i'd say this fits well for stuff you may want to merge in the future

18:00 <d1b2> <Attie> sounds good... I'm tempted to go for BSD-3-Clause for the moment, and can relicense if/when it gets merged

18:00 <electronic_eel> as long as all contributors agree, you can relicense whenever you want

18:01 <electronic_eel> whitequark is not a fan of licensing that has any kinds of restrictions (like gpl)

18:02 <d1b2> <Attie> sounds good (i think)

18:02 <d1b2> <Attie> i'm pretty much at the end of the add-on now... if anyone would be willing to give it a quick look-over that would be very kind (be nice 🙂 )

18:02 <d1b2> <Attie> https://github.com/attie/glasgow-can

18:02 <electronic_eel> i don't think 3-clause-bsd will make any significant difference for you compared to 0-clause. if some chinese vendor wants to make and sell your board, they don't care about any kind of license

18:03 <d1b2> <Attie> yeah, very true

18:03 <electronic_eel> also i guess you have better things to do with your time than sueing someone over a licens violation

18:03 <d1b2> <Attie> most likely.

18:04 <electronic_eel> i can take a look at your can addon, maybe some time over the weekend

18:08 <d1b2> <Attie> thanks!

22:07 <d1b2> <0x53A> Does glasgow also support influxdb 2 or only 1.x? I'm asking because in version 2, authentication via a token seems to be required, but there is no token parameter anywhere in the help or in the source code.

22:09 <whitequark> only 1.x

22:10 <d1b2> <0x53A> alright, I'll try to add support for 2.x, seems like an easy first task

22:15 <whitequark> yup

23:38 <d1b2> <Foone> So I'm playing with some hacking on a video-output applet and I'm falling back to playing with video-vga-output as a template, but I've hooked it up to the oscilloscope and I'm not seeing anything that makes sense on the output. I think I may be running this wrong? For applets like this, do I need to something other than "python -m glasgow.cli run video-vga-output" to activate the output? it seems to exit almost immediately.

23:39 <d1b2> <Attie> the VGA applet should show a test pattern on a VGA monitor

23:39 <d1b2> <Attie> there's nothing "to do", so it loads the bitstream and exits

23:39 <d1b2> <Attie> have you wired up resistors and a monitor (or similar)?

23:40 <d1b2> <Foone> no, I'm just putting a resistor across pin 1 (vsync) and ground. I expect I should see a ~60hz signal

23:41 <d1b2> <Foone> err, an oscilloscope. not a resistor

23:41 <d1b2> <Attie> hmm

23:41 <d1b2> <Attie> pin 0 defaults to hsync, so you should see a ~khz signal

23:42 <d1b2> <Attie> (unless you've changed it)

23:42 <d1b2> <Attie> and the video-vga-output is the correct applet / should work correctly

23:43 <d1b2> <Foone> hmm, ok, yeah. I switch to 0 and I'm seeing a 31.3khz signal, which is in the right range

23:43 <d1b2> <Attie> here's me playing with it, with an example of the test pattern https://youtu.be/9kCGYm2fY7k?t=8170

23:45 <d1b2> <Attie> re 31.3kHz, nice!

23:45 <d1b2> <Attie> pin 1 should probably be ~60Hz

23:46 <d1b2> <Foone> the voltage is a bit questionable. It seems to be 360mv on pin 0? I did "python3 -m glasgow.cli test video-vga-output -V 3.3 --port A" to ensure it was at the right voltage.

23:46 <d1b2> <Attie> huh, that's unexpected - nothing wired up aside from glasgow -> scope?

23:47 <_whitenotifier-f> [glasgow] 0x53A opened pull request #240: add InfluxDB2DataLogger (cli name influxdb2) to log into an InfluxDB 2.x - https://git.io/JIs0H

23:48 <d1b2> <Foone> oh god damn it, I forgot this stupid probe has a tiny switch in it to put it in 10x mode. it's actually 3.6v

23:49 <d1b2> <Attie> i was about to suggest that 😄

23:49 <d1b2> <Attie> mine sees the signal a little hot too - ~3.4v

23:50 <electronic_eel> is it 3.6v on the vio also?

23:50 <electronic_eel> that would be a bit much for 3.3 set voltage

23:50 <d1b2> <Attie> i can confirm ~3.34v on my Vio, not sure what tolerance you're expecting

23:51 <whitequark> 5%

23:51 <electronic_eel> 3.34 v is fine, this is not a high precision voltage calibrator

23:51 <d1b2> <Foone> I'm seeing 3.36v on vio. I was just measuring with a manually positioned cursor, so probably any inaccuracy was just me not measuring accurately

23:51 <electronic_eel> but the 3.6v from foone seem to be a bit much to me

23:52 <electronic_eel> ok .3.36 seems more like it

23:57 <d1b2> <Foone> thanks for the help. the good news is that this confirms I'm not using it wrong and my hardware isn't broken. that just means that my code is broken, which is annoying because now it means I gotta fix it.

23:58 <d1b2> <Attie> yay / doh

23:59 <d1b2> <Attie> i had just one glasgow running the SCD30 applet, and started the VGA applet on another, which knocked out the first, because I think glasgow list updated the firmware even though it was in use