<rqou>
too bad this is conducted emi so afaik fcc doesn't really care
<awygle>
lain: are you doing anything that's actually sensitive to such things?
<lain>
awygle: I'm not aware of it interfering with any of my SDR stuff, but it does cause various power filters and appliances to buzz like angry hornets at times
<balrog>
that's not "harmful interference"?
<awygle>
lain: ooo that's irritating yeah
<lain>
that's how we originally noticed it
<awygle>
put a huge cap on your mains input to filter out the noise! /s
<lain>
haha
<lain>
it's pretty interesting to see how various power supplies effect the noise
<rqou>
awygle: good for improving power factor :P
<rqou>
(not really true in a modern house)
gnufan has joined ##openfpga
<awygle>
i wonder if i could do QPSK demod in an ice40up
<rqou>
probably?
<rqou>
they built modem chipsets out of completely potato discrete devices
<rqou>
*modems
<rqou>
before there were chipsets :P
<awygle>
i'm pretty sure they did analog demodulation then
<rqou>
yeah
<awygle>
which is also an option i guess
* rqou
really wants to play with coding
<rqou>
but i kinda sucked at ee126, so :(
<awygle>
like FEC?
<rqou>
yeah
<rqou>
also fountain codes
<lain>
I'm looking forward to playing with ALL THE RADIO schemes when my fancy SDRs get here
<lain>
got some XTRX's
<awygle>
lain: ooo
<rqou>
btw, a random idea that i've had for a while is to make a set of "pedagogical" crypto/compression/coding/signals/controls libraries so that people stop thinking these topics are magic
<rqou>
but i don't really have much time to do this and idk how many people would actually care
<awygle>
but then we can't charge as much :p
<awygle>
lain: oh god so many u.fl's
<lain>
:>
<kc8apf>
ITAR training I went through clearly stated that a US citizen sharing information covered by ITAR with a foreign national is a violation. Doesn't matter where it physically occurred.
<kc8apf>
there were examples shared of accidental violations from nearly everyone who does ITAR work
<rqou>
O_o
<awygle>
lain: i have a limesdr mini but nothing in particular to do with it
<lain>
awygle: I want to play with various encoding schemes, get a more practical grasp on QAM and whatnot, and generally immerse myself in it for fun
<lain>
and then listen to /everything/
<lain>
:P
<awygle>
hahaha
<awygle>
i want to characterize my LNB board
<rqou>
lain: RE some of those "digital voice" protocols?
<rqou>
for some reason all of these are random proprietary garbage
<rqou>
which is weird because voice/audio compression just isn't _that_ interesting
<rqou>
(neither is video, but the mpeg-la obviously doesn't agree)
<awygle>
kc8apf: the wrinkle in rqou's hypothetical for me was that the RE is in some sense "creating" the information outside the country
gnufan has quit [Ping timeout: 260 seconds]
<awygle>
i agree that it'd almost certainly come down as a violation though.
<kc8apf>
would highly depend on if you had been previously exposed to information about the tech being RE'd
<lain>
quick video of FFT of the mains here while running the inverter microwave
<lain>
you can see the microwave kick on around 4 seconds, and then its noise slides over and it starts to resonate with the upper peak of the mains noise
gnufan has joined ##openfpga
<rqou>
an inverter microwave? how boring :P
<lain>
hehe
<rqou>
you can't even make entertaining videos of shocking yourself like that iranian guy :P
<lain>
the inverter microwave dumps a lot of noise on the mains, it's pretty great
<lain>
you notice a lot of weird stuff when you're running an FFT of your electrical system 24/7 lol
<rqou>
why?
<rqou>
why are you doing that?
<lain>
rqou: we were trying to find the source of an annoying buzzing sound that pops up sometimes (the two peaks in the video before and after the microwave runs, at around 11khz and 23khz)
<rqou>
ah ok
<lain>
so we logged when it occurs and graphed it over an extended period of time, and it correlated inversely with outside temperature
<lain>
and then we eventually determined it's most likely a faulty ingition system in the neighbor's oil-burning furnace :P
<lain>
as a result of this I wound up building a little esp8266 board that plugs into an outlet and samples the mains waveform, streaming the data back to a central logging server... I hope to make it identify "weird crap" and catalogue it. I might have too much free time.
gnufan has quit [Ping timeout: 264 seconds]
<lain>
also I'm the type who always wonders what the mains waveform looked like right after some weird event, like the lights flickering or etc
<rqou>
you know people have been doing that for years by tapping into kill-a-watt devices, right?
<qu1j0t3>
kc8apf: Yeah i found that, figured i'd dive into something lighter first :)
<awygle>
Came home to a kit and two stencils, guess I've got stuff to do this weekend now lol
<rqou>
for smolfpga?
gnufan has quit [Ping timeout: 264 seconds]
<awygle>
Yeah but I don't have the smolfpga board yet. So I'll assemble my LNB with the other stencil.
<awygle>
I should have paid for faster service, whoops
<rqou>
$$$
<rqou>
or actually just $ for oshpark
<awygle>
10$ vs 5$
<rqou>
yeah, hence just $
<rqou>
also, rust procedural macros feel a bit more gimped than they could be
<rqou>
i really want procedural macros that are hooked in after scopes/identifiers are resolved
<rqou>
not just accepting raw tokens
<rqou>
also, this is gross: `std::iter::Map<std::vec::IntoIter<syn::LitStr>, F>`
gnufan has joined ##openfpga
<rqou>
why is everyone obsessed about vga/vga-like controllers for fpgas?
<rqou>
these are really really trivial
<rqou>
they're basically just two counters
<rqou>
and some comparators
<qu1j0t3>
hehe
<qu1j0t3>
because it's a highly visible achievement. the blink-LED of fpga? maybe
<rqou>
probably
<jn__>
blink-LED is already the blink-LED of fpga
<rqou>
lol
<jn__>
but yes, "look, i can do video output!!!"
<jn__>
i'd be happy about that, too :)
<qu1j0t3>
right, it has more brag worthiness
<sorear>
real-time video output is also something you can't do sensibly on a uc
<qu1j0t3>
^
<qu1j0t3>
good point
<rqou>
except propeller? :P
<sorear>
(sensibly is doing a nontrivial amount of work)
<sorear>
maybe propeller.
<sorear>
well
<sorear>
is propeller fast enough to do anything on a 25mhz dot clock?
<rqou>
idk lol
<rqou>
i know they have some kind of hardware assist for video generation
<rqou>
like a shift register or something
<rqou>
back in the day a bunch of people made video demo things with it
<sorear>
20 MIPS at max clock when programmed in assembly, 1/200 of that in their HLL
<rqou>
(not that the chip was actually any good lol)
<rqou>
also, the prop2 has been vaporware for like 5+ years now
gnufan has quit [Ping timeout: 264 seconds]
digshadow has quit [Ping timeout: 256 seconds]
<rqou>
troll idea: put a propeller cog into azonenberg's antikernel noc :P
<rqou>
hey, it's inherently multicore with a weird "hub" thing already! :P
gnufan has joined ##openfpga
noobineer has quit [Ping timeout: 256 seconds]
noobineer has joined ##openfpga
eightdot_ has joined ##openfpga
eightdot has quit [Ping timeout: 264 seconds]
gnufan has quit [Ping timeout: 265 seconds]
gnufan has joined ##openfpga
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined ##openfpga
Zorix has quit [Remote host closed the connection]
<gruetzkopf>
XMOS's chips could be a lot of fun if they had practical external memory interfaces
digshadow has joined ##openfpga
mumptai_ has joined ##openfpga
noobineer has quit [Remote host closed the connection]
mumptai has quit [Ping timeout: 255 seconds]
<awygle>
azonenberg: what's the deal with KSZ9031 packaging?
<awygle>
the RNX datasheet lists three different packages, all of which are RNX. none of the options in the part number decode specifies which package it is.
<awygle>
azonenberg: yes, but none of that says "3.5mm pad or 5mm pad"
<awygle>
and both are listed in the datasheet as packages
<azonenberg>
wait the thermal pad changed?
<azonenberg>
interesting
<rqou>
wait wtf
<rqou>
you can select what bond material you want?
<azonenberg>
rqou: during the transition period
<azonenberg>
you can order Au bonded parts while inventory remains
<azonenberg>
if you really care
<azonenberg>
i think they're not making it anymore
<azonenberg>
Basically rather than giving a change notice that the same SKU is a new bond wire material
<azonenberg>
they changed the SKU
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
bitd has joined ##openfpga
gnufan has quit [Ping timeout: 264 seconds]
gnufan has joined ##openfpga
rohitksingh has joined ##openfpga
fouric has quit [Ping timeout: 276 seconds]
fouric has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
flaviusb has joined ##openfpga
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined ##openfpga
<pie_>
whitequark, "FLG1928 has only around 300 GPIOs, but 72 transceivers (and most balls are power), or as I've described it on IRC, "none FPGA with left GTX"" but y
<azonenberg>
pie_: why did he call it that, or why does it only have 300 GPIOs?
<pie_>
why does it have 228 power balls
<pie_>
might as well go with a smaller package (?)
<azonenberg>
pie_: it has closer to a thousand power balls
<awygle>
pie_: power net impedance, probably
<azonenberg>
well power + ground
<azonenberg>
but yes
<azonenberg>
Vias and BGA balls look like inductors at a few hundred MHz :p
<awygle>
Every doubling of ground balls halves inductance to ground and lets you go twice as fast (to first order)
<awygle>
Also for a big honking fpga like that one there may be a real current issue as well, if you drop to few enough balls
<awygle>
idk how many amps per ball is safe but I bet it's not many
<azonenberg>
awygle: a professor of mine at RPI actually did research on solder metallurgy
<azonenberg>
focusing on electromigration risk in BGA balls]
<azonenberg>
and die solder bumps especially
<azonenberg>
apparently they tend to form single large grains of crystalline tin taking up most of the ball, which is bad
<awygle>
... Yes
<azonenberg>
because tin is very mechanically weak in one crystal axis and very susceptible to electromigration in another
<awygle>
I'm guessing that's lead free solder?
<azonenberg>
SAC305 i think was the base alloy they started with
<azonenberg>
So he was exploring additives to shrink the grain size and get a smaller polycrystalline structure
<azonenberg>
which would balance out the two orientations to avoid weak spots
<awygle>
I'm no metallurgist but I have the impression lead prevents tin from doing Bad Crystal Things
<awygle>
(Or growing hair)
<azonenberg>
lol
<awygle>
tin whiskers give me the heebie jeebies
<awygle>
in a similar way to like, moss, or the seeds inside bell peppers
<azonenberg>
hey, if a SOIC doesn't want to shave its legs and let the hair grow
<azonenberg>
what right do you have to say it needs to shave?
<azonenberg>
:p
<awygle>
BRB asking wife to conformal coat her legs
<azonenberg>
lol
* awygle
is not married and would never do such a thing
<azonenberg>
i guess pantyhose is kinda like conformal coating? or woudl it have to be those latex fetish ones
<azonenberg>
in all seriousness, i have yet to see whiskers in any of my designs
<azonenberg>
So i'm not sure what conditions they're a problem in or if i just don't have enough pcb's for it to be a problem
<azonenberg>
I generally use sac305 on the cool side of the process window on enig
<azonenberg>
with either sac305-balled BGAs or NiPdAu leaded components
<awygle>
I don't think anyone is sure what conditions cause whiskers
<awygle>
But vibration seems to exacerbate
<azonenberg>
A few are bright tin but NiPdAu seems to be getting more common, which i like
<awygle>
anyway, pie_ has been answered, it'll be tomorrow in 30s, I'm going to bed
<jhol>
mithro: hi! - I've just been talking with edmund and david about VPR ice40 synthesis
<mithro>
Hi jhol
<jhol>
hi - I don't know if you heard, but I'm doing a bit of work for symbiotic
<mithro>
jhol: Yes
<jhol>
and I heard you need to demo ice40 VPR by the end of the month
gnufan has quit [Read error: Connection reset by peer]
<mithro>
jhol: Well, I'd like to get something working ASAP - I think the sooner we have something working the sooner we can start figuring out if the work we are doing is worth the effort
<jhol>
I'm available to help with that if you need
<jhol>
so last summer I was tinkering with my own attempt at an architecture XML for the ice40
<jhol>
got as fast as describing the tiles, but got sidetracked before solving the switchbox and routing aspect of it
<jhol>
your repo looks much more sophisticated than what I got to
<mithro>
jhol: We have the tiles description down pretty well
<mithro>
jhol: But have yet to get the switchbox and routing stuff finished
<jhol>
tiles are the easy part!
<mithro>
jhol: I have a tool which imports the routing from icebox and tries to generate an rr_graph
<jhol>
the main issue with the routing I encountered, is that those things are not well documented in icestorm - just the raw nets in the, which is no good for an arch xml
<jhol>
whats the benefit of patching? sounds fragile
<mithro>
jhol: Patching provides a mechanism for double checking that you are doing the right thing -- it's very easy to generate an rr_graph which is "correct" in the sense it loads into vpr but then causes vpr to crash/segfault/do the wrong thing
<mithro>
And I don't mean "literal patching" (as in running the patch command) - I mean in loading an existing rr_graph and then generate a new rr_graph based on that
<jhol>
sure
<mithro>
Plus if we get enough confidence - maybe we can just do direction generation
<jhol>
sure
<jhol>
so is anyone working on this right now? or are you focussing on other things?
<jhol>
I'm happy to start working on it
<mithro>
digshadow: is working on it - and I work on it when I get sick of doing the things that I should be doing :-P
<jhol>
what's the best way for me to help?
<mithro>
jhol: I created some simple "testarch" to better help understand rr_graph creation and patching
<digshadow>
I added some getting started stuff there
<mithro>
jhol: Not sure when digshadow will be next around -- but he just went through this process so probably a good person to learn from
<jhol>
digshadow: hi!
<digshadow>
there are also a few fixes on my branch
<digshadow>
hi jhol
<jhol>
digshadow: so are you actively working on this? I'm here to help, but I don't want to end up duplicating effort
<digshadow>
jhol: I started working on it relatively recently and I'm still getting a hang of things. mithro might be able to provide some better direction on how work could be split up
<jhol>
ok, no problem - well as I say I'm going to start playing with thus on Monday, so I think that's the first step, then we can talk about the way forward
<digshadow>
sounds good, I'll be more available on monday. Right now refinishing my hardwood floors...
<jhol>
yeah - know feeling - my daughter just learned how to climb out of her cot and run amok
<mithro>
jhol: Feel free to ping me any time too
<jhol>
thanks
carl0s has joined ##openfpga
carl0s has left ##openfpga [##openfpga]
_whitelogger has joined ##openfpga
gnufan has quit [Ping timeout: 260 seconds]
<whitequark>
awygle: so I wrote the FPGA bitstream download code
<whitequark>
in 8051 assembly
<whitequark>
I'm not entirely sure if that was necessary but
<awygle>
whitequark: sweet
<awygle>
i was gonna do the other footprint(s?) you assigned me now
<awygle>
... after some coffee maybe
<whitequark>
rqou: btw I don't think you can terminate ULPI on an iCE40 FPGA
<whitequark>
and get high speed
<whitequark>
they're simply not fast enough to build a SERDES, the IO buffer is too slow
gnufan has joined ##openfpga
<whitequark>
awygle: it runs puts bits into the FPGA at a whopping 6 MHz
<awygle>
does ftdi even actually do 480 Mbps?
<whitequark>
in theory it's possible to use GPIF to stream data directly from USB endpoints but that requires transmitting each bit as its separate byte and also the host will need to know the pinout partially
<whitequark>
or the pinout would have to be locked in all hardware revisions etc
<whitequark>
so I think it's not worth the hassle
<awygle>
ah
<whitequark>
FTDI is a high-speed device I believe but it can't utilize 480 Mbps because the external interfaces are fairly slow
<whitequark>
I think
<whitequark>
we can do up to 384 Mbps with a 8-bit bus, which is plenty enough
<whitequark>
especially given protocol overhead
<whitequark>
this might come in handy for ETM or ITM
<awygle>
isn't ulpi only 60 MHz, SDR or DDR? seems like ice40 should be able to do that
<awygle>
always unnerving when robots tell me what i just did
<whitequark>
awygle: going straight for the hard ones huh
<awygle>
whitequark: well, swallow the frog and all that
<whitequark>
do what
<awygle>
i don't really know the origin of it (seems to be a quote attributed to mark twain) but it's a phrase in "productivity" literature that says you should do the most unpleasant thing you have to do today first so your day can only get better
<whitequark>
but my day is full of things that are one less pleasant than other
<awygle>
yeah it's not actually particularly useful
<awygle>
i just try to do things from hard to easy where possible
<whitequark>
okay, going home now, gonna test bitstream download