azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-cmake, https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal | Logs: https://freenode.irclog.whitequark.org/scopehal
bvernoux has quit [Quit: Leaving]
<kc8apf> azonenberg: do you know if anyone has looked at how Cypress implements eFUSE?
<azonenberg> kc8apf: not aware
<kc8apf> hmm. hopefully they are visible on the die images when I get them.
<monochroma> what cypress family?
<kc8apf> I'm looking at PSoC 6
<azonenberg> kc8apf: did you look at the psoc5 die shots on siliconpr0n?
<azonenberg> unsure if they're the same process or not
<kc8apf> i'm having die shots taken of a psoc6
<azonenberg> but there were multiple memory arrays there
<kc8apf> I can wait
<azonenberg> i mean for reference of what to expect
<kc8apf> oh, sure
<monochroma> ah, there is significant research done on some of the PSoCs, iirc they found what were labeled as fuses were just flash, and iirc not even dedicated flash for a "fuse area" just part of the bulk flash
<kc8apf> the docs talk about multiple chunks of flash but they talk about efuse as something diffferent
<kc8apf> psoc4 was rather different from what psoc6 is describing
<monochroma> oic
juli964 has quit [Quit: Nettalk6 - www.ntalk.de]
<azonenberg> https://www.kickstarter.com/projects/azonenberg/akl-pt1-2-ghz-passive-oscilloscope-probe It's live! Now taking preorders for the probes
<monochroma> :D!
<azonenberg> not bad, it's been live for less than an hour and i have two people getting the commercial edition probe and one who wanted a bare pcb
<lain> :D
<azonenberg> WOW
<azonenberg> ok THIS is interesting
<azonenberg> Pico probe in red, my probe in blue, lecroy 1M passive probe in cyan, Tetris/ZS1500 active probe in black
<azonenberg> Input impedance
<azonenberg> It's interesting to note that the lecroy datasheet's curves shows the Zin just touching 100 ohms at about 1.5 GHz, while I measure the Tetris at 30 ohms
<azonenberg> but more interesting is how well my probe tracks the tetris after ~150 MHz
<azonenberg> From 200-675 MHz I actually have less loading than the active probe, it wins from 675 - 1.6 GHz but not by that much, then i pull ahead until 2.8 GHz
<azonenberg> So either i'm doing something wrong, or the tetris actually has worse loading characteristics than the datasheet would imply :p
<azonenberg> also interesting that all of these probes have a peak about the same height and shape, but at different places
<azonenberg> The TA061 and my probe were measured on full 2-port configs with the VNA on the other side
<azonenberg> the lecroy probes were measured with the other end mated to a scope since they're not 50 ohm output, so i measured S11 only
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #scopehal
<azonenberg> (refreshed that plot with the Picoconnect probe in pink)
<monochroma> buttery smooooth
<azonenberg> yeah that pico probe is AMAZING
<azonenberg> it's the best probe i've ever got my hands on by far, on every metric i can measure
<azonenberg> Except for the awkward ergonomics
<_whitenotifier-9> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JfYAO
<_whitenotifier-9> [starshipraider] azonenberg 1294540 - Continued work on TCP-UART bridge
<azonenberg> Wooo first signs of life from TCP transmit
<azonenberg> it can now send a single segment
<azonenberg> Nothing after that works because it doesn't bump the sequence number
<azonenberg> so the stack discards all further traffic
<azonenberg> but i'm close to having working-if-no-packets-are-lost tcp transmits
<azonenberg> which should be complete enough that i can start a scopehal driver
juli964 has joined #scopehal
anuejn_ is now known as anuejn
m4ssi has joined #scopehal
<azonenberg> TCP implementation is coming along
<azonenberg> There's some quirks to iron out still though
<azonenberg> I'm getting content back intermittently but there's bugs. Not yet sure if in the TCP code or the UART bridge
<azonenberg> Well, at least one race condition in the uart bridge
<azonenberg> under some conditions the "data ready" flag outruns the data in the fifo :p
<_whitenotifier-9> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JfOf9
<_whitenotifier-9> [starshipraider] azonenberg ed91c55 - Continued work on TCP UART bridge
<_whitenotifier-9> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfOfQ
<_whitenotifier-9> [starshipraider] azonenberg 79044c6 - Updated ipcores
<Degi> Yay!
<azonenberg> It's alive!
<azonenberg> No retransmits yet, and it ignores the RX window size and always sends TX window of 1024. So still some work to be done
<azonenberg> But it's at least alive enough i can get data back. Which means i can start writing the other code that talks to it
<Degi> Lol the 1.5 GHz probe makers apparently dont know the 3 dB rule
<azonenberg> I mean it is possible that there are issues in my measurement setup. But so far it looks like that probe is not nearly as good as it's advertised
<azonenberg> It's an OK, but not very flat, 1 GHz probe
<azonenberg> It's not a 1.5 IMO
<Degi> Could those oscillation-like things be a thing of your probing setup?
<azonenberg> I think it's unlikely they're not really there
<azonenberg> i literally jammed the probe right into a SMA and VNA'd it
<Degi> Hmh
<azonenberg> So what i'm trying to figure out now is why my simple code is using half the ram on a 7a100t
<azonenberg> something in my stack is probably unoptimized and much bigger than it should be
<Degi> Huh
<Degi> Thats quite a bunch
<azonenberg> Yeah. I have some arbiters with bigger buffers than necessary i think. Let me shrink those a bit
<azonenberg> The IPv4TransmitArbiter is also just inefficient in general, i can definitely do better on that
<azonenberg> but 128K of buffer in the arbiter is probably excessive as well :p
<Degi> Heh
<azonenberg> you mean the ground pulling back from the CPW?
<azonenberg> or the little dark area in the center trace
<azonenberg> That's not a cut, that's soldermask
<Degi> Oh
<azonenberg> I have little bars of soldermask after pads to keep solder from flowing out onto the trace and messing with the impedance
<Degi> Ahh yes otherwise the solderw ould flow out
<azonenberg> ok so i changed some defaults in the stack, let's see how much smaller the ram usage gets now...
<azonenberg> Better. Now I'm at 8% LUT, 4% LUTRAM, 4% FF, 37% BRAM, 16% IO, 22% BUFG, 17% MMCM
<azonenberg> This is for the whole TCP/IP stack, the TCP-UART bridge, and the HMCAD1520 controller but no logic to bridge the ADC's output to the TCP core yet
<azonenberg> And no DDR3 controller because there's no DDR3 on an integralstick
<azonenberg> there's two hyperrams, but those don't have nearly the bandwidth i'd need for this so i'm not going to bother using them
<azonenberg> Anyway, at this point i need to build an arbiter between the UART bridge and the HMCAD1520 controller
<azonenberg> then i can start building some sort of buffering engine to handle the waveform data
<azonenberg> oh and of course some kind of trigger system
<Degi> Maybe just a loooooong FIFO or a buffer that gets filled, a flag gets raised and then it gets sent over TCp
<Degi> Maybe then we can measure THD and frequency response
<azonenberg> My plan is to have a basic level trigger at a hardcode level to start
<azonenberg> we'll set up something more sophisticated later. I just want to get data right now
juli965 has joined #scopehal
juli964 has quit [Ping timeout: 256 seconds]
bvernoux has joined #scopehal
<bvernoux> hello
<bvernoux> azonenberg, nice the crowdfounding campaign !!
<azonenberg> bvernoux: yeah it seems to be getting some traction, it's 35% of the way to being funded after less than 24 hours
<bvernoux> yes great
<bvernoux> CrowdSupply is nice for crowdfounding too more specialized in Electronic stuff but less visibility
<bvernoux> so KickStarter seems to be a good things
<azonenberg> Yeah. Also you missed this last night https://www.antikernel.net/temp/tcp-progress.png
<azonenberg> the fpga tcp core reached a level of completion that i can actually talk to it. It has no tolerance for dropped packets because i don't actually store packets for retransmit, or do anything with inbound ACKs, yet
<azonenberg> But the everything-is-working-OK path is complete
<azonenberg> I think at this point i'm going to start writing the ADC-to-TCP bridge and a scopehal driver for the prototype
<azonenberg> it won't work over slow connections and will completely fall apart if you drop even one packet, but my LAN is reliable enough it should work most of the time and when it fails, it will be obvious
<azonenberg> then in parallel i can finish the tcp core
<azonenberg> but i want to get the whole system working even if not super robust yet for testing
<bvernoux> ha great
<bvernoux> FPGA TCP works !!
<azonenberg> i also still have to do more work around window size logic
<azonenberg> i have hardcoded 1024 for inbound and ignore the window size outbound
<azonenberg> So a fair bit of work left before it's done and anywhere near RFC compliant
<bvernoux> How many cells are taken by IP/TCP stack ?
<bvernoux> I suspect it is far less than something with a soft MCU+sw TCP/IP stack ...
<azonenberg> As of right now the entire test design including the ADC controller mostly optimized out because the waveforms don't go anywhere, tcp/ip stack (icmp, arp, RGMII bridge, udp that is mostly optimized out, TCP), and TCP-UART bridge
<azonenberg> is 8% LUT, 4% LUTRAM, 4% FF, 37% BRAM, 16% IO, 22% BUFG, 17% MMCM on an xc7a100t. There are a few arbiters and clock domain crossings in the stack that are very inefficient with memory and i think i can cut the bram usage way down
<azonenberg> but that's the state as it stands now
<bvernoux> xc7a100t is quite expensive
<bvernoux> about >130USD/unit
<azonenberg> yes i would like to fit the final board into smaller but we'll see. that's what the devkit i'm using has
<bvernoux> ha yes ok
<bvernoux> 37% BRAM seems a lot
<bvernoux> I see there is about 600KBytes BRAM in this FPGA
<bvernoux> anyway I imagine with TCP/IP stack if you reserve space for at least 10 connections it consume already about 80KB ...
<azonenberg> yes. There's some inefficient buffering in the stack i will be working on optimizing later
<azonenberg> But we're a long ways off
<azonenberg> I will be using DDR3 for the TCP buffer in the final system
<bvernoux> ha yes great like that you can reserve the precious BRAM for other stuff
<azonenberg> But that 37% doesn't include tcp buffering
<bvernoux> will be nice with an ECP5-5G ;)
<bvernoux> as they are clearly less expensive
<azonenberg> there are however some large fifos and arbiters that i can shrink deeper down in the stack
<azonenberg> Like i said this is early unoptiimized code
<bvernoux> yes it is already very nice for an alpha version working
<bvernoux> You should push details of the KS on Tweeter I will repost it if that can help
<azonenberg> I tweeted it already
<azonenberg> it's pinned to my profile, feel free to share it
<bvernoux> azonenberg, I can do that with my AirSpy account with more than 5K followers ;)
<bvernoux> lot of HAM guys but I'm pretty sure few will be interested to have a nice 50 Ohm Probe
<azonenberg> Go for it
<bvernoux> Done ;)
<bvernoux> Done with my 3 Twitter account ;)
<bvernoux> I'm impatient to see final version of the probe ;)
<azonenberg> final or KS version? :p
<bvernoux> final ;)
<bvernoux> but the KS one is already very very good
<bvernoux> my Auburn Probe is far from it I think ;)
<azonenberg> well the graphs you see there are from the current beta. The KS version is going to be the final form factor with final ground lead placement, i don't have characterization results from that board rev yet
<azonenberg> then i plan to do additional simulations and modeling and try to push a respin of that board (tweaking the tip and SMA match mostly i think) out to ~4 GHz
<bvernoux> ha yes it will be amazing to see if it can be pushed to 4GHz+
<bvernoux> Using other SMA connector ;)
<bvernoux> SMA connector have big impact I think
<azonenberg> Yes. That is going to be a big part of it for sure. This "18 GHz" connector seems like it's going to be a huge pain to push faster
<bvernoux> use the one I'm testing up to 26.5GHz with very nice price at Powell ;)
<bvernoux> it shall be caracterized but it seems really better without tuning
<bvernoux> as it is already tuned by design
<azonenberg> Before we talked i had already ordered the Amphenol part I mentioned
<azonenberg> It claims 26.5 GHz so we'll see how it actually does out to 6 in my testing
<bvernoux> ha yes interesting
<azonenberg> it's the same style with the V-shaped ground contacts and tiny center pin
<lain> bvernoux: did you make airspy, or?
<bvernoux> yes I think it will have similar perf to the one I use
<bvernoux> lain, yes
<azonenberg> this weekend i'm going to design and order a tiny test board with two of them back to back on an oshpark PCB
<lain> oh neat
<bvernoux> lain, I'm the creator of full HW & Embedded Software+PC Tools
<bvernoux> lain, AirSpy R0 to R2 & AirSpy Mini
<bvernoux> lain, not the HF stuff
<bvernoux> I only play in HF stuff related to NFC ;)
<lain> :D
<bvernoux> soon I will release HydraNFC v2 with an amazing tuning & perf )
<bvernoux> the best existing so far
<bvernoux> everything is done frome scratch Antenna + PCB + Tuning with my VNAs ...
<bvernoux> done with 4 iterations during months
<bvernoux> Using 4 tunable capacitors ;)
<bvernoux> so you can read NFC with metal behind totally amazing
<lain> oooo
<lain> that will be handy
<bvernoux> it is for research first board
<bvernoux> as it can act as sniffer active/passive and of course reader for everything ISO TypeA, B, V, F ...
<bvernoux> Idea behind is to exploded security in NFC using some new attacks based on passive/active sniffer with some probes to check if there is leakage of secret like AES keys ...
<lain> very fun
<bvernoux> There is clearly no HW today to do that
<bvernoux> as modulating NFC field is pretty hard and cannot be done with a simple SDR
<bvernoux> for other guys it will be a very nice reader reading at >15cm with my CreditCard size Antenna ;)
<bvernoux> by default there is more than 1.5W power and external Amp are possible ;)
<lain> wow
<bvernoux> example of reading range with default board https://twitter.com/hydrabus/status/1224075657702969346
<bvernoux> if you want to see the AutoTuning effect with 4 varicaps => https://twitter.com/hydrabus/status/1224061743372161024
<bvernoux> and there was only 16steps in this example as we can have 256steps ;)
<bvernoux> using a 8bits DAC
<lain> niiice
<bvernoux> waiting the PCB from USA ;)
<bvernoux> I was not lucky with this COVID as I have launched prod in February
<bvernoux> and the PCB was finished 7 April
<bvernoux> and locked in CHICAGO since 13 April...
<bvernoux> Fab is done at MacroFab
<bvernoux> They have a very good service where everything is done online
<lain> ah yeah, I used them for my product for quite a while
<lain> very happy with the results
<bvernoux> But as I live in France it is not the best for me for shipping
<bvernoux> I plan to use Macrofab fulfillment maybe in future to sell stuff in USA
<bvernoux> for high quality products
<bvernoux> as they are still quite expensive vs China for PCB+Assembly
<bvernoux> lain, if you are interested by NFC I will release a Sigrok/Pulseview plugin to decode everything on the mysterious NFC chipset on HydraNFC v2 ;)
<bvernoux> lain, I plan to provide more details on this famous chipset when the boards will be available for shipping
<bvernoux> schematics will be probably released too all is done with KiCad 5.x ;)
<bvernoux> for information AirSpy are all designed on KiCad too ;-) even if the schematics board are not open source
<lain> :)
<bvernoux> full SW are full open source anyway
<bvernoux> it is the most important I think
<bvernoux> as I doubt anyone could build an AirSpy R2 at home with schematics and part ;)
<bvernoux> so far I have never received any Email toward that
<bvernoux> to ask for schematic ...
<bvernoux> block diagram and main components are already described with a photo of the PCB
<bvernoux> It is why sometime for some products Open Hardware is not really required especially when they are very compact and complex to build at home
<bvernoux> also for good news I shall receive the DSLogic U3Pro16 in middle of May
<bvernoux> I will open it directly to do High-Res Photo of the PCB ... ;)
<bvernoux> I have not seen any review of it so far and it seems it is available since March 2020
<bvernoux> This week end (tomorrow) I finally plan to solder my TRL Board v0.1 ;)
<bvernoux> to do VNA test with TRL
<bvernoux> and check the Johnson/Cinch/Bel SMA High Freq End Launch connectors 142-0771-831
<bvernoux> now I have received the Glue which is good thanks to Mouser for fast shipping
<bvernoux> Does anyone here have CNC ?
<bvernoux> I think it is the next things I will like to have to design some RF box, cavity filters ...
<bvernoux> as 3D printer for metal parts (even just aluminum) are clearly too expensive today ...
<Degi> Hm you can do lost foam casting and then polish it
<bvernoux> yes could be a good idea
<bvernoux> need to check what is it ;)
<bvernoux> and how to do that with what result especially accuracy is a must have for RF microwave stuff
<Degi> Eh the accuracy comes from grinding it by hand I guess
<Degi> Its pretty rough
lain has quit [Quit: kthxbai]
lain has joined #scopehal
<Degi> Can we have an isolated DC DC converter at the input?
m4ssi has quit [Remote host closed the connection]
tnt has quit [*.net *.split]
tnt has joined #scopehal
bvernoux has quit [Quit: Leaving]
zkms is now known as smkz