<rqou>
cyrozap: also at least in Apt. A none of the POTS is live either
<rqou>
amongst millennials, only weird people who live on islands with unreliable power (azonenberg :P ) even use POTS anymore
<cyrozap>
rqou: The TWC (err, Spectrum) demarc at my apartment is literally in a hole in my closet wall, and they give you the option to split it out to all the cable jacks in the apartment. Since I don't have cable TV, I just connected the cable they gave me to the cable that goes straight to my modem. Unfortunately, I can't quite get up to my 300 Mbps maximum thanks to either my modem's (or maybe the CMTS's)
<cyrozap>
bufferbloat issue or the attenuation in the cable.
<rqou>
heh we don't even have 300mbps
<rqou>
we get up to about 100mbps
<cyrozap>
I know, I know, "Poor cyrozap, he only gets 220-250 Mbps instead of 300 Mbps." :P
<rqou>
the way the cable works in our apartment is that the Comcast cable comes into the wiring/junk closet under the stairs
<rqou>
it goes into a 4-way splitter
<rqou>
two go to apt b and c
<rqou>
one goes somewhere I couldn't find
<rqou>
and the last one goes upstairs near our fire escape
<rqou>
then that goes into a 2-way splitter
<rqou>
one end goes back downstairs and enters the living room where we have a cable TV for some reason even though it doesn't get watched
<rqou>
the other end goes into my room and then becomes too short
<rqou>
so then it goes into a coupler and another RG6
<rqou>
then it goes under the door of my room, is taped around the doorframe, and then finally into the cable modem
<rqou>
for a final power of about -12dbmV and a SNR of about 30-32dB
<rqou>
aka "just barely works"
<cyrozap>
rqou: If you want to find the other end of that cable, attach an SDR to the end you know the location of, transmit a bunch of noise, and then roam around with a second SDR until you see the signal coming out the other end.
<rqou>
or just unplug it and see which neighbor complains? :P
<cyrozap>
Oh, it's connected. I thought you were talking about a cable that might be leaking RF or something.
<rqou>
it might be connected, I don't know
<rqou>
but if you unplug it and nobody complains, it probably wasn't connected :P
fengling has joined ##openfpga
uwe_ has quit [Ping timeout: 264 seconds]
uwe_ has joined ##openfpga
<rqou>
although this heuristic doesn't actually work too well here because we don't even know our neighbors :P
<rqou>
including where we haven't been approached regarding our "colorful" wifi ssids :P
fengling has quit [Ping timeout: 252 seconds]
uwe_ has quit [Ping timeout: 268 seconds]
uwe_ has joined ##openfpga
fengling has joined ##openfpga
ZipCPU has joined ##openfpga
ZipCPU has quit [Ping timeout: 268 seconds]
ZipCPU has joined ##openfpga
ZipCPU has quit [Client Quit]
ZipCPU has joined ##openfpga
<qu1j0t3>
is it really so clear who they belong to though?
m_w has quit [Quit: leaving]
digshadow1 has quit [Read error: Connection reset by peer]
digshadow has joined ##openfpga
amclain has quit [Quit: Leaving]
<mithro>
Does anyone have a recommendation for a high pin count (~150 IOs), low cost, FPGA/CPLD for routing ~100MHz signals
<mithro>
A digikey search seems to suggest a MachXO3
<dingbat>
If you're willing to work with lattice tools, yes. Otherwise, a smaller Artix 7, a middling Spartan 6/7, or a middling MAX 10
<dingbat>
mithro: how low cost is low cost?
<mithro>
dingbat: under $10 USD
<dingbat>
mithro: In quantities of 1 or quantities of 1k?
<mithro>
dingbat: quantities of about ~250
<dingbat>
An Altera Max V might work for you, but yes, in generally, Lattice parts are going to be cheaper
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
lain has quit [Quit: updoots]
pie_ has quit [Changing host]
pie_ has joined ##openfpga
promach has quit [Ping timeout: 260 seconds]
promach has joined ##openfpga
lain has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<openfpga-github>
[openfpga] rqou opened issue #72: mingw/Windows: some combination of build tools causes warnings about -fPIC https://git.io/vyOfI
uwe_ has quit [Ping timeout: 264 seconds]
digshadow has quit [Read error: Connection reset by peer]
digshadow has joined ##openfpga
<rqou>
digshadow: before i forget/mess up again, is mtvre going to be tomorrow, next week, or the week after next?
<digshadow>
rqou: in one week
<digshadow>
I was trying to get confirmation on second talk
<rqou>
alright
<digshadow>
but I should just send out announcement
uwe_ has joined ##openfpga
Hootch has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
Hootch has quit [Read error: Connection reset by peer]
<azonenberg>
Try adding a print statement to src/gpdevboard/utils.cpp:88
<azonenberg>
see how many times it's being hit
<azonenberg>
and if there's a visible delay between prints
<rqou>
right, i'll do that in a bit
<azonenberg>
its possible something funky is happening elsewhere in the driver stack?
<rqou>
going to mess around with macos first
<rqou>
it's quite possible; windows and drivers are always fun
<azonenberg>
Ok i'm about to get some sleep
<azonenberg>
Comment on the issue with your findings
pie_ has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
Bike has quit [Quit: sleep]
<nats`>
azonenberg board sent to fab :)
<nats`>
and I'm prototyping a cheap GHz BW sampler for test purpose at first we will see how I can handle a finished one :)
<openfpga-github>
[openfpga] rqou opened pull request #73: contrib: Add a codeless kext to make gp4prog work on macOS (master...macos) https://git.io/vyORU
scrts has quit [Ping timeout: 264 seconds]
scrts has joined ##openfpga
<openfpga-github>
[openfpga] rqou opened issue #74: build system: Make "distclean" target work https://git.io/vyOut
<openfpga-github>
[logtools] rqou opened pull request #3: Windows fixes (master...rqou) https://git.io/vyOz6
massi has joined ##openfpga
massi_ has joined ##openfpga
pie_ has joined ##openfpga
<openfpga-github>
[openfpga] whitequark closed issue #74: build system: Make "distclean" target work https://git.io/vyOut
<openfpga-github>
[openfpga] whitequark commented on issue #74: (also, `git clean` is the command you should use instead of doing that manually anyway.) https://git.io/vyO2S
<openfpga-github>
[openfpga] rqou opened pull request #75: Minor fixes for macOS and Windows (master...minor-fixes) https://git.io/vyOa4
<openfpga-github>
[openfpga] rqou opened issue #76: Find a volunteer to pay the Apple tax https://git.io/vyOaX
<openfpga-github>
[openfpga] whitequark pushed 4 new commits to master: https://git.io/vyOVC
<openfpga-github>
openfpga/master fd53445 Robert Ou: gpdevboard: Don't try to detach kernel driver on Windows or macOS...
<openfpga-github>
openfpga/master 06ad0a9 Robert Ou: gp4prog: Use _getch rather than termios on Windows...
<openfpga-github>
openfpga/master a230023 Robert Ou: gp4prog: Include <cstdlib>...
<openfpga-github>
[openfpga] rqou commented on issue #70: Fixed by fd534451a681863bb00bc87417a008d1577e1023 https://git.io/vysR7
nanoUIUC90s has joined ##openfpga
nanoUIUC90s has left ##openfpga ["Saindo"]
<openfpga-github>
[openfpga] rqou opened pull request #77: gpdevboard: Don't exceed the usleep limit on certain platforms (master...minor-fixes) https://git.io/vysuR
<openfpga-github>
[openfpga] whitequark commented on issue #78: Well gpcosim is not useful without iverilog, is it? https://git.io/vys2Y
<openfpga-github>
[openfpga] rqou commented on issue #78: Theoretically you should be able to use another Verilog simulator along with gpcosim (e.g. a proprietary one). Not sure why exactly you would do that, but... https://git.io/vys2W
<azonenberg>
rqou, whitequark: Prtoper solution i think is to just make gpcosim optional if vpi_user.h isn't found
<azonenberg>
Having the generated gpcosim binary be covered by GPL is unavoidable for the short term, unless we can find another source for the VPI api
<azonenberg>
I never fully implemented gpcosim anyway so its not a big deal
<rqou>
yeah right now the autobuilds just comment it out
<azonenberg>
rqou: Re the usleep limit
<azonenberg>
is it working on windows now? :p
<rqou>
presumably you can do the "two independent people" technique and scrub the ieee1364 vpi_user.h in annex g
<rqou>
yeah it work on windows now
<openfpga-github>
[yosys] azonenberg pushed 22 new commits to master: https://git.io/vys2x
<openfpga-github>
yosys/master 5f1d0b1 Clifford Wolf: Add $live and $fair cell types, add support for s_eventually keyword
<openfpga-github>
yosys/master 6d7a77d Johann Klammer: Did as you requested, /but/......
<openfpga-github>
yosys/master 06df86a Johann Klammer: add options for edif flavors...
<rqou>
anyways, who here has _NOT_ opened IEEE1364 before and wants to participate in Yet Another Attempt to liberate vpi_user.h? :P