whitequark[cis] changed the topic of #glasgow to: https://glasgow-embedded.org · digital interface explorer · https://www.crowdsupply.com/1bitsquared/glasgow · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.irclog.whitequark.org/glasgow · matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
notgull has joined #glasgow
notgull has quit [Ping timeout: 245 seconds]
Eli2 has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
Lord_Nightmare has quit [Quit: ZNC - http://znc.in]
Lord_Nightmare has joined #glasgow
smkz has quit [Quit: smkz]
smkz has joined #glasgow
smkz has quit [Client Quit]
smkz has joined #glasgow
cr1901_ has joined #glasgow
cr1901 has quit [Ping timeout: 260 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
<theorbtwo[m]> Allo, dumb question time... I'm having some difficulty following the instructions for what connects where. Does "Conductors 8-23 are crimped to connect to pins 3-18 of connector A;" imply that floppy 3-> A0, floppy 5->A1, etc?
Wanda[cis] has joined #glasgow
<Wanda[cis]> ohh, floppy applet?
<Wanda[cis]> so, no
<Wanda[cis]> this means that floppy 8 -> pin 3 of the overall A connector [ie. pin A0]
<Wanda[cis]> if you're not following the instructions for IDC cable crimping and are just using dupont wires instead (like I did), it's likely easier to just follow the default pin assignment list in --help and some reference for floppy pinout
Guest68 has joined #glasgow
Guest68 has quit [Client Quit]
bvernoux has joined #glasgow
<theorbtwo[m]> Ah, didn't realize --help would tell me, I've just been reading the code, and it seems the pin assignments happen by magic.
<Wanda[cis]> the defaults are auto-assigned, yes
<theorbtwo[m]> Yeah, I'm using esden's wires and plugging them each in by hand, with a magnifying glass. (I hate that I'm loosing my vision.)
<whitequark[cis]> people really do not read `--help` and then suffer, constantly
<whitequark[cis]> this is the standard for CLIs for 30 years, why are you not using it?
<Xesxen> to be fair, --help in a lot of programs tends to be a couple pages worth of documentation so I tend to also forget it exists...
<whitequark[cis]> why is that fair? it's documentation. read it!
<whitequark[cis]> it's basically the only documentation for applets currently
<theorbtwo[m]> I read the code that generates the help output. I didn't realize that also reading the help output itself woudl be ... er ... helpful.
<whitequark[cis]> why start with reading the code in first place...
<whitequark[cis]> sure, it's written readably, but we also have actual documentation
<whitequark[cis]> (why do I bother writing it if people don't read it anyway? maybe I should only write the code then)
<Xesxen> (please continue making them)
<theorbtwo[m]> Right. After figuring out some inconsistant naming -- "drive sel 0" in the samsung document vs "motea" in the glasgow command line and wikipedia -- it turns out that the --help output is in agreement with what I thought... which sadly doesn't match what I actually wrote.
<theorbtwo[m]> Please continue making them. I just wish they were next to the other documentation.
<theorbtwo[m]> FWIW, I tend to prefer not --help documentation these days because webby docs have a slightly better reading interface.
<whitequark[cis]> but the CLI is exactly where you're using it
<whitequark[cis]> (formatting the docs to look OK both in the terminal and in the web browser is kind of a pain, though it's potentially doable; I basically need to vendor a markdown parser or something)
<theorbtwo[m]> Well, it's going. Wish me luck.
<whitequark[cis]> good luck
<whitequark[cis]> note that the PLL in the applet is somewhat flawed and depending on how bad your drive is, it might need a little nudge to lock onto the bitstream
<whitequark[cis]> this all is in software, so once you take a bitstream dump from the floppy, you can leave the hardware aside
<theorbtwo[m]> Hm. Attempted two different discs, and pulled apart and re-connected my wiring... it gets to just past "starting up the drive", and stalls with the motor running and nothing in particular happening.
<theorbtwo[m]> More worrying, the motor keeps running if I control-c and glasgow safe, but stops if I actually hit the button on the glasgow.
<whitequark[cis]> you're not getting any data
<whitequark[cis]> dunno what's up with glasgow safe, interesting result
<whitequark[cis]> i think you're not connecting rdata correctly
<whitequark[cis]> actually wait
<_whitenotifier-e> [glasgow] whitequark opened pull request #563: cli: use `asyncio.run()` - https://github.com/GlasgowEmbedded/glasgow/pull/563
<_whitenotifier-e> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-563-5b98678cd7858e796ed27e3eb79d791512dfc8ac - https://github.com/GlasgowEmbedded/glasgow
<theorbtwo[m]> Wait...?
<whitequark[cis]> sorry, I got distracted
<whitequark[cis]> are you using --pulls?
<theorbtwo[m]> No.
<_whitenotifier-e> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±2] https://github.com/GlasgowEmbedded/glasgow/compare/5b98678cd785...11223134c9b3
<_whitenotifier-e> [GlasgowEmbedded/glasgow] whitequark 1122313 - cli: use `asyncio.run()`.
<_whitenotifier-e> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-563-5b98678cd7858e796ed27e3eb79d791512dfc8ac - https://github.com/GlasgowEmbedded/glasgow
<theorbtwo[m]> Right. Way happier with --pulls. I feel like, at least for things where the interface is specified "all the way down" like this, --voltage and --pulls should come with correct defaults.
<whitequark[cis]> --pulls should probably just not be an option yea
<whitequark[cis]> it is for historical reasons
<whitequark[cis]> you can remove it and send a PR, I'll rubberstamp it
<whitequark[cis]> --voltage is harder
<whitequark[cis]> I fundamentally agree but argparse is limiting
gsuberland has quit [Ping timeout: 245 seconds]
gsuberland has joined #glasgow
GNUmoon2 has quit [Ping timeout: 260 seconds]
GNUmoon2 has joined #glasgow
funkeleinhorn[m] has joined #glasgow
<funkeleinhorn[m]> Would it be possible to use the iCE40 for RF applications? Especially in the 1.9GHz band? I was wondering if the Glasgow could be turned into an SDR 🤔
<whitequark[cis]> i once made the glasgow into a 133 mhz transmitter by toggling a pin real fast
<whitequark[cis]> it transmitted some am audio (iirc, diggy diggy hole) that could be picked up on 133. and the next harmonic. and the next 7 or 8 harmonics after that
<whitequark[cis]> so, probably dont do that
notgull has joined #glasgow
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #glasgow
notgull has quit [Ping timeout: 268 seconds]
trappedinpajamas has joined #glasgow
<trappedinpajamas> (still cleaner than a baofeng)
<whitequark[cis]> oof
<trappedinpajamas> for ""serious"" applications, it may be possible to do JESD207 using the expansion LVDS expansion. Not sure if the ice40 can do it, lattice IP only works for ecp3 and above apparently. Those RF chips are not cheap though.
<whitequark[cis]> ice40 is not a lattice fpga
<whitequark[cis]> it's a siliconblue fpga (common misconception)
<trappedinpajamas> ! correct (hence the SB_ prefix)
cr1901_ is now known as cr1901
<whitequark[cis]> and lattice fpgas are mostly although not entirely at&t fpgas
<whitequark[cis]> also known as lucent, also known as alcatel-lucent, also known as ...
<whitequark[cis]> there are at&t primitive names to this day in ecp5
<whitequark[cis]> at least i think that's what those are
_whitenotifier-e has quit [Ping timeout: 260 seconds]
lethalbit|wut has joined #glasgow
lethalbit has quit [Ping timeout: 260 seconds]
cyborg_ar has quit [Ping timeout: 260 seconds]
cyborg_ar has joined #glasgow
tom has quit [Remote host closed the connection]
<theorbtwo[m]> I wonder how clean a signal you can get using lots of pins to make a resistor ladder dac. Extra points for making it so you can move a jumper or similar to double the number of channels and halve the bit depth.
<whitequark[cis]> hm... it's more about the rise time I think
<whitequark[cis]> needs a filter
lethalbit|wut has quit [Quit: kill -9 -1]
DX-MON has quit [Quit: I'm not disconnecting, you're disconnecting!]
DX-MON has joined #glasgow
lethalbit has joined #glasgow
prop_head_mania[ has quit [Quit: Idle timeout reached: 172800s]
<josHua[m]> I pasted a screenshot of this thread elsewhere, and the universal reaction was 'That's a very whitequark thing to do.', to which I agreed (and then corrected them that you prefer to be referred to as Catherine). but I think if there were a Catherine.txt, this would be high up on the list.
<whitequark[cis]> lmao
<whitequark[cis]> let me find you the video
<josHua[m]> yeah, this tracks
<tpw_rules> i did that with a propeller back in the day
<whitequark[cis]> it was incredibly easy to do with glasgow
<whitequark[cis]> it was literally just `m.d.comb += pins.o.eq(ClockSignal() & audio_out)`
<josHua[m]> the inverse of an analogous thing was a nerd sniping of ~10 years for me
<whitequark[cis]> oh like, sampling?
<whitequark[cis]> someone did BLE reception with an ECP5 serdes recently
<josHua[m]> let me see if I can find my blog post on it
<josHua[m]> The French Madman at some point released some pixmaps that if you configured your X server just right, caused a DVB-T signal to show up on a harmonic of the red channel of your VGA ADC
<josHua[m]> and I was like 'well obviously if he can encode them then I can decode them'
<josHua[m]> and it turns out that I was about to spend the next 11 years Learning Something.
<josHua[m]> s/ADC/DAC/
<whitequark[cis]> oh, fabrice bellard
<whitequark[cis]> i like how he was like "yeah I can stream video too, contact me for details" and then not released anything (not)
<josHua[m]> yeah it is very bellard.txt
<josHua[m]> with the processing power available at th etime that would probably be pushing it a little bit but I would imagine he could do it
<whitequark[cis]> if anyone could optimize it he's definitely high up on that list
<josHua[m]> with the processing power available today I imagine that I could do it.
<josHua[m]> I think the thing that I never really understood how to do in a semblance of realtime was the band pass filter to make the resampling work
<josHua[m]> though I should, like, maybe revisit that as a 35 year old instead of as a 20 year old hotshot
windbg[m] has quit [Quit: Idle timeout reached: 172800s]
<theorbtwo[m]> This whole floppy thing is driving me mad, and making me feel incompetent. It doesn't help that I almost certianly am incompetent, compared to many of you.
<whitequark[cis]> it's probably just a poorly written applet tbh
<theorbtwo[m]> Once I've done the "applet" bit of it and gotten the raw flux image, what am I supposed to do with it in order to progress it toward something I can actually read enough to see if it makes any sense / is possibly actually a correct image? `glasgow tool memory-floppy raw2img -t 18 ultma-underworld.raw ultma-underworld.img` seems to be what I'm supposed to do, but it produces a ton of bad-looking debug output and a file consisting only
<theorbtwo[m]> of zeros.
<whitequark[cis]> "something like that"
<whitequark[cis]> the PLL probably can't lock onto the bitstream
<whitequark[cis]> I want to emphasize again: "This applet is PREVIEW QUALITY and may CORRUPT DATA or have missing features. Use at your own risk."
<whitequark[cis]> you're currently experiencing the "your own risk" part
<whitequark[cis]> I know that the digital PLL I'm using isn't especially good (I never found out exactly why) and the way it's being used can result in poor performance on certain bitstreams
<whitequark[cis]> * on certain flux bitstreams
<theorbtwo[m]> Ah. This is actually a major step forward for me -- I have an excuse for it not working for me.
<whitequark[cis]> one sec
<theorbtwo[m]> Does it make sense to take that raw file into some other floppy-dicing-and-slicing tool? Any hints as to which and how?
<whitequark[cis]> s/reducing/narrowing/
<whitequark[cis]> is this a HD floppy? then, iirc, something like min=46 max=50 should work
<whitequark[cis]> if this is a DD floppy, then min=94 max=98
<whitequark[cis]> <theorbtwo[m]> "Does it make sense to take..." <- i dont use other tools 😎
<whitequark[cis]> except for openocd i guess. openocd is too useful
<theorbtwo[m]> 3.5 inch HD.
<galibert[m]> I think I have the wd1772 pll in amaranth somewhere if you want it
<whitequark[cis]> yeah try 46/50 or 47/49
<whitequark[cis]> the NCO is insufficiently disciplined
bvernoux has quit [Quit: Leaving]
threeflour[m] has joined #glasgow
<threeflour[m]> Catherine do you have a link to the ECP5 BLE reception you could share? I'm familiar with https://github.com/newhouseb/onebitbt, but its using a Xilinx FPGA.
<whitequark[cis]> oh I misremembered which FPGA it was
<threeflour[m]> Thanks for responding so fast, I was hoping someone had figured out how to get the ECP5 serdes to not sync to the RX data.
<whitequark[cis]> hm
<whitequark[cis]> I think Maya maybe knows something about it
<whitequark[cis]> she did the most reverse-engineering of the ECP5 serdes of anyone I know
gsuberland has quit [Remote host closed the connection]
gsuberland has joined #glasgow
<threeflour[m]> Thanks! I appreciate you pointing me that way.