<azonenberg>
Just had a nice chat with the signalpath guy. I'll be sending him one of the probes when they're ready
<azonenberg>
one populated board naked so he can show it off without disassembly, and one populated probe with accessories and cal cert
<azonenberg>
one finished probe with shell*
<azonenberg>
also i'm working on a respin of the probe shell that slightly thins out the shell toward the tip. will be a bit less rigid but fit in tighter spaces better
<azonenberg>
we'll see how i like both variants
<lain>
oh neat
<lain>
how'd you run into him?
<azonenberg>
Messaged him on twitter
<azonenberg>
also not sure if you saw earlier but paperwork with Symbiotic is signed, the sponsorship deal for the probes is official
<lain>
sweet!
<azonenberg>
they'll be sending me $3k towards the cost of the VNA next business day
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfeGS
<_whitenotifier-3>
[starshipraider] azonenberg 7a0c15b - New shell with thinner tip
<azonenberg>
hmm, shapeway didn't like that one for some reason
<azonenberg>
"problem with 3d processing, please try again"
<azonenberg>
and seems to be fixed
<azonenberg>
So i should be getting a pretty nice range of enclosure options by a week from tuesday (current ETA)
anuejn_ has joined #scopehal
vup2 has joined #scopehal
vup has quit [*.net *.split]
anuejn has quit [*.net *.split]
asy has quit [*.net *.split]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg>
ook so i think hardware has gone about as far as it can until prototypes come back. Gonna be getting back to the TCP stack shortly
<azonenberg>
as of right now it can ack incoming syns/fins etc but not respond properly to frames containing actual data
<azonenberg>
segments*
<azonenberg>
and cannot send any data
<azonenberg>
with any luck i can get it working before the adc board is ready
vup2 is now known as vup
<azonenberg>
degi, electronic_eel: Thoughts on the Mini-Circuits SRSC-4-63+ for ZENNECK?
<azonenberg>
We will definitely want to do some fine tuning, possibly digital postprocessing, on the individual interleaved adc's but i think it's a good start
sorear has quit [Ping timeout: 240 seconds]
sorear has joined #scopehal
<Degi>
Hm its still single ended, but it could be okay yeah
<azonenberg>
i think most of the differential paths will be single ended 50 ohm internally
<azonenberg>
we just have to carefully match propagation delays
<azonenberg>
Also, i just finished preliminary testing of rx-only tcp
<azonenberg>
it can send acks etc but has no data or retransmit functionality
<azonenberg>
no tx data*
<azonenberg>
So i'm going to shift gears a little bit away from fpga side and start writing some scpi parsing code on the stm32
<azonenberg>
plan is to have a uart for scpi traffic from fpga to mcu, one way for now, with the other leg of the uart going out a gpio to an actual usb-uart dongle
<azonenberg>
so i'll send scpi commands in over the socket and get replies over usb-uart
<azonenberg>
high level block diagram of the BLONDEL mainboard
<azonenberg>
am i missing any major subsystems?
<Degi>
800 MT/s of 64 bit data?
<azonenberg>
Degi: yes, that's the raw line rate of the DDR3L
<azonenberg>
We need to be able to write 8 bits * 1 GS/s for each of two ADCs and two LAs, so 32 Gbps of writes
<azonenberg>
And then potentially up to 10 Gbps of reads, which is 42 Gbps
<azonenberg>
We have 51.2 Gbps of memory bandwidth before overhead, so to saturate 10GbE we'd need to hit 82% bandwidth utilization which is pushing it
<azonenberg>
RLE compression on the LA will help a lot too
<Degi>
rle compression?
<azonenberg>
Run length encoding
<azonenberg>
store (value, number of copies) tuples instead of raw samples
<azonenberg>
if you expect at least 50% of your samples to have no toggles, you save space
<azonenberg>
and more importantly, bandwidth
<azonenberg>
we could potentially delta-code analog waveforms too, but i don't think that will save much and is likely not worth it
<azonenberg>
anyway, starting out i'll only do 1G ethernet
<azonenberg>
then worry about 10G later
<electronic_eel>
why only 4gbyte of sodimm? will it be possible to upgrade to 16gbytes?
<electronic_eel>
the 16gb modules are only about 100 bucks
<Degi>
Huh thats pricy
<Degi>
Did ram prices kinda stagnate in 2015?
<electronic_eel>
ddr3 sodimms with 16gbytes are a bit exotic, they came out only later in the scheme of ddr3l
<electronic_eel>
8gb is more common
<electronic_eel>
also the prices tend to stick to the last prices when a ram generation was mainstream
<electronic_eel>
now ddr4 is mainstream, so you see prices going down only there
<electronic_eel>
ddr3 keeps a common level, unless there is some major market disturbance, then the prices go up everywhere
<Degi>
hm can you easily parallel RAMs?
<electronic_eel>
not all systems can do it and the load you can put on one bank is limited
<electronic_eel>
so usually you can just parallel certain sodimm types, not all. I think this is called "rank"
futarisIRCcloud has joined #scopehal
<electronic_eel>
some are single rank, others are dual rank
<electronic_eel>
and most boards can't put two dual rank dimms on one bank
<azonenberg>
electronic_eel: i was looking at a $20 sodimm :p
<electronic_eel>
but there are some that can do it
<azonenberg>
with a bitstream change, any ddr3l should work. not sure if i will support single or dual rank
<azonenberg>
7 series cannot do ddr4
<electronic_eel>
azonenberg: I was looking at max possible memory, didn't care for price at all
<azonenberg>
in that case, we might have to do a custom build of firmware for you but it's totally possible. I'll be routing all of the address lines
<azonenberg>
i will be 1.35V only so DDR3L, not DDR3
<azonenberg>
lower power and has same performance limited by the 7 series IOBs
<electronic_eel>
yes, ddr3l is the more modern variant
<azonenberg>
its annoying looking at newegg
<azonenberg>
they list ddr3 and 3l in the same category and you have to filter by voltage
<electronic_eel>
no problem with a custom gateware, the most important part is that all address lines are routed
<balrog>
DDR3L generally can operate at DDR3 voltages
<electronic_eel>
I suggest we give the users some recommended ram vendors / models and they can select what they want
<azonenberg>
Yes that is the plan. And necessary timings
<electronic_eel>
or play with it themselves, no guarantees
<azonenberg>
since with the xilinx controller i think you have to bake timing into the IP, i dont think it lets you runtime configure
<azonenberg>
(i could be wrong on that)
<Degi>
Oof
<Degi>
Well yeah thats kinda the problem with IPs
<azonenberg>
I'm all for using a third party, more flexible controller at some point in the future
<azonenberg>
but starting out the priority will be making it work, and a ddr controller is annoying enough i really don't want to write my own right now
<balrog>
it seems the lack of compatibility with ddr4 has more to do with it using pseudo open drain
<azonenberg>
balrog: correct
<azonenberg>
7 series does not have POD drivers, only SSTL
<balrog>
how does lpddr3 work in comparison?
<azonenberg>
LPDDR3 is still SSTL just lower voltage
<balrog>
(though lpddr3 is not available in module form which doesn't help)
<azonenberg>
yes, lpddr3 does not seem cost effective for most applications these days unless you have crazy volume
<azonenberg>
ddr3l can be bought at amazon, newegg, etc from pc part vendors so it's dirt cheap
<balrog>
why is it so popular in low power devices -- is it that much more efficient than ddr3l?
<balrog>
or ddr4
<azonenberg>
(also has anyone mentioned that naming such different standards so similarly is confusing? lol)
<balrog>
oh it very much is confusing
<electronic_eel>
just the naming is easy. if you begin to look at single rank vs. dual rank and so on, then you can have some fun
<azonenberg>
LPDDR3 is apparently tuned for mobile device applications and focuses on lower idle power
<balrog>
azonenberg: there's one lpddr3 available on the open market, a 8Gbit chip for about $20
<azonenberg>
DDR3L is meant for power optimized servers
<azonenberg>
balrog: how wide is the bus?
<balrog>
256M x32
<azonenberg>
also apparently 7 series doesnt even have a lpddr3 controller?
<balrog>
yeah probably not
<balrog>
so it won't help you
<azonenberg>
at least in the 2017 dated datasheet i have
<azonenberg>
they have lpddr2, ddr3, and ddr3l
<azonenberg>
and ddr2
<balrog>
I'd stick with ddr3l :)
<electronic_eel>
balrog: but for the $20 you get a whole sodimm with 8 of these ics
<balrog>
yup
<balrog>
unless you're building something that needs to last long on a battery, it's pointless
<azonenberg>
Yeah exactly. for $20ish i can get a whole sodimm with 32 Gbits of DDR3L
<azonenberg>
*and* i get an x64 bus
<Degi>
Hmm do they have hardware controllers?
<azonenberg>
they have hardware io blocks that are used by mostly soft controllers
<azonenberg>
it may well be possible to write a lpddr3 controller for a 7 series part
<azonenberg>
the question is why?
<azonenberg>
a socketed ddr3l sodimm is the most cost effective way to get lots of ram imo
<balrog>
yeah you want lots of RAM, not a smaller amount of power efficient RAM
<balrog>
which means a socketed ddr3l sodimm is the way to go
<electronic_eel>
azonenberg: in your BLONDEL block diagram there is no specific thing telling where the fpga bitstream is coming from. I guess from the flash of the stm32?
<Degi>
Yeah I just wondered if they actually have hardware controllers or whether its all gateware
<azonenberg>
electronic_eel: no
<azonenberg>
the fpga will boot in master spi mode off an attached spi flash
<azonenberg>
i didn't show that, the jtag connectors, etc. the focus is on showing major dataflow
<electronic_eel>
how do you easily change bitstreams then?
<azonenberg>
electronic_eel: jtag
<Degi>
Huh
<Degi>
No lan upgrades?
<azonenberg>
that's by far the easiest option for dev. much faster than writing to flash
<electronic_eel>
huh? like open the case and stuff?
<Degi>
Hm is the jtag connected to the STM too?
<azonenberg>
for development, yes. you can jtag the fpga waaaay faster
<azonenberg>
the fpga and stm32 will be on one jtag chain
<azonenberg>
tentatively
<Degi>
So you could use the STM32 as a JTAG mater
<Degi>
*master
<azonenberg>
no no no
<azonenberg>
yo
<azonenberg>
you stick an ftdi dongle into the case and jtag the fpga+mcu at once during development
<azonenberg>
The fpga has a spi master IP on it and we can easily add a self programming mode for field firmware updates
<azonenberg>
to write the attached flash
<Degi>
Hm right
<azonenberg>
but this isn't how dev will work. Dev units likely won't even write the fpga flash at all
<Degi>
Yeah I wanted to implement that on the ECP5 with UART too cause for some reason OpenOCD cant program the flash easily
<azonenberg>
the mcu flash has to be written because stm32 firmware is normally not relocatable
<azonenberg>
So we can't just jtag code into ram and execute that without a special build of the firmware, and ram is tight anyway so wasting it on code is stupid
<electronic_eel>
for development I think it is very convenient to have some jtag on there all the time
<electronic_eel>
but for the users later on I don't like that at all
<azonenberg>
users won't be using jtag
<Degi>
Yeah I think I've never written the flash on the ECP5 too, bitstream straight into the core... Though I kinda made the data in the flash unusable sometime
<azonenberg>
it's for dev and production prorgamming
<azonenberg>
There will definitely be a self programming mode for field updates
<electronic_eel>
but when that fails?
<Degi>
Externally accessable jtag maybe
<azonenberg>
maybe tftp initiated by a front panel menu or something
<azonenberg>
When that fails you jtag it. That should be an extremely improbable event
<electronic_eel>
here is how I would do it for later users:
<electronic_eel>
have the bitstream in the stm32, send it from there via spi to the fpga on boot
<azonenberg>
how does that help anything?
<azonenberg>
also, i don't even know if it will fit
<azonenberg>
let me check something, sec
<azonenberg>
stm32f777 has up to 2 MB of flash
<azonenberg>
That's 16 Mbits
<electronic_eel>
the stm32 has a bootloader in its flash, when the scope starts you have like 2 seconds to trigger it with a button
<azonenberg>
an xc7a100t bitstream is 30 Mbits in size
<Degi>
Yeah thats too little I think? (At least for the ECP5 like 64 Mbits is recommended, I think the xc7 is bigger?)
<azonenberg>
if you want golden and fallback images you're talking about a 64 Mbit spi flash
<electronic_eel>
when the bootloader is triggered with the button, it will take a known good firmware from a separate spi flash and write that into its flash
<azonenberg>
i guess you could hang this off the stm32 but now you're running in x1 mode vs quad spi so boots are slower
<azonenberg>
electronic_eel: xilinx has a built in multi-boot mode where you can fall back to a golden image on the other half of flash if the primary is corrupted/fails to boot
<azonenberg>
all we need is a few bitstream generation settings and a quad spi flash with enough space for two copies of the bitfile
<azonenberg>
one factory programmed and never touched and only used for recovery, the other reflashed when we issue updates
<electronic_eel>
when you want to update firmware, you send it via tcp->serial to the stm32, it does checksumming and then writes it to the spi flash
<electronic_eel>
on the next boot the bootloader writes it into the regular flash of the stm32
<Degi>
Ooh check out MRAM
<electronic_eel>
ok, we could use the xilinx multi-boot
<azonenberg>
also, if the fpga bricks the stm32 loses network connectivity
<electronic_eel>
but how do we ensure that the stm32 and the fpga always have matching firmwares?
<azonenberg>
as it runs the lan interface
<Degi>
electronic_eel: Maybe add something like a version number
<azonenberg>
My proposal is for firmware updates to be implemented via TFTP in gateware
<azonenberg>
fpga.bin and mcu.bin or similar filenames
<azonenberg>
the stm32 has enough flash for a trivial bootloader and two full copies of app firmware as well
<electronic_eel>
tftp sucks
<Degi>
Hm FPGAs load their bitstream once at boot, then the flash can be written and then a reboot triggered, right?
<azonenberg>
yes. you can write the flash once the fpga is loaded
<electronic_eel>
I hate having to set it up for old gear that doesn't have http fw updates
<azonenberg>
and it won't touch anything until the fpga reboots
<Degi>
Hm yeah we could implement a http server or so
<azonenberg>
all we'd need to do for matching is to have the mcu-fpga interface include a version number query function
<electronic_eel>
that is why I think having tcpip on the stm32 would make stuff easier
<Degi>
Hm theoretically you could checksum the firmware as a version identifier
<azonenberg>
honestly, though, i intend for the two to be pretty independent. the fpga will do data plane and the mcu control plane, and they'll rarely if ever talk to each other directly
<azonenberg>
the mcu will reconfigure the adcs/dacs and the fpga will just stream waveforms
<electronic_eel>
you could take some http code for stm32 and use it, without having to implement some gateware monster for it
<azonenberg>
electronic_eel: what about running updates through the scpi interface?
<azonenberg>
just provide a file transfer command there
<azonenberg>
and provide a utility for flashing it
<electronic_eel>
how would the user input the firmware there?
<Degi>
Hm re dual boot: In my PC the BIOS has two flash ICs, where if a flash fails it can boot from the other and retry and if it was successful, you can flash the new firmware to both flash chips
<azonenberg>
Command line flasher tool?
<electronic_eel>
ok, that could work
<Degi>
I mean you need drivers anyways, yeah sounds good
<azonenberg>
anyway, my point is that since the mcu and fpga kinda live in separate worlds
<azonenberg>
update to one or the other shouldn't be likely to break anything
<electronic_eel>
now you have the firmware in the stm32, how does the fpga bitstream get there?
<azonenberg>
well, since the fpga is doing tcp and proxying the scpi data out to the mcu
<Degi>
Maybe load it into RAM and then write to flash
<azonenberg>
just have the mcu send a command to the fpga saying "start writing scpi data to flash" or similar
<azonenberg>
once the headers etc have been sent
<Degi>
Wow SCPI looks wack, like the text case
<azonenberg>
then anything coming in on the socket until a stop command is received goes to flash
<Degi>
Hmm
<electronic_eel>
hmm, that violates my concept of layers a bit too much
<Degi>
I'd like writing to RAM and then checksumming
<azonenberg>
Degi: we do not have nearly enough ram on the stm32
<Degi>
And then checksumming again after the write is done
<azonenberg>
we could write to DDRx i guess
<Degi>
I mean the DDR3L
<azonenberg>
my plan was to write to fpga flash, verify that
<azonenberg>
if it fails display an error message
<azonenberg>
board remains fully usable as long as you don't reboot, if you do reboot it'll revert to the fallback image
<electronic_eel>
I would send it to the stm32 and have it send it to the fpga over a separate control uart or similar
<Degi>
How does it know to revert to fallback? Configuration on the screen?
<azonenberg>
electronic_eel: that would be much slower, the fpga has a quad spi link to the flash
<azonenberg>
Degi: the fpga always tries to boot primary
<azonenberg>
if the crc in the bitstream fails to verify, it falls back to the secondary
<Degi>
I mean you can switch which one to boot somehow
<Degi>
Ah neat
<electronic_eel>
speed is not really a problem here, won't care if it would take a minute or so
<electronic_eel>
this is not for development where you do that all the time
<electronic_eel>
the user would do that every few weeks or even months
<Degi>
Ooh how about being able to update while sampling?
<azonenberg>
Degi: by having the update running on the control plane socket, the sampling logic is totally unaffected
<Degi>
Hm right
<azonenberg>
however, commands to query/modify channel configuration would be temporarily blocked
<Degi>
I guess theres some disruption when rebooting the fpga
<azonenberg>
it's no different than a linux kernel update where you apply it then can reboot at any time in the future to make it take effect
<azonenberg>
you can schedule the downtime at your leisure
<azonenberg>
re fpga reloads, the bitstream is ~30 Mbits in size, quad spi can go up to ~100 MHz * 4 bits = 400 Mbps
<azonenberg>
so you're looking at, roughly, 100ms of load time, then a short period for ethernet link to re-establish
<azonenberg>
i would expect the system to be fully functional in well under a second after power is applied or a reset request is issued
<azonenberg>
obviously all open sockets will drop
<Degi>
Huh 400 Mbps
<Degi>
Hmm is it always 30 Mbits?
<azonenberg>
If you don't compress, it's 30606304 bits
<azonenberg>
+/- slight variations for adding things like a multiboot header
<azonenberg>
if you compress, it can be smaller
<electronic_eel>
azonenberg: even if the fpga bitstream is on a separate spi flash, please plan a small (4mbytes) spi flash for the stm32
<azonenberg>
Where "compression" is just a coarse lempel-ziv that involves replaying entire frames of configuration data when you have multiple unused block rams or regions of lut logic in a row
<azonenberg>
electronic_eel: oh? what would we need it for
<electronic_eel>
so that we can have 2 copies of the stm32 code in there
<azonenberg>
the mcu has two flash banks onboard, 1 MB each, and is explicitly designed for dual panel updates
<electronic_eel>
golden master and current one to update
<azonenberg>
you can execute out of one (or ram) while writing to the other
<azonenberg>
plan is to have bootloader + golden master in one bank and the working image in the other
<electronic_eel>
but don't you need to relocate the code for the one you are using?
<azonenberg>
No. When you start an update, jump to the update code in the first bank
<azonenberg>
blow away the second, then flash the update to it
<azonenberg>
when starting up, always begin in the first bank, run a crc on the second
<azonenberg>
if it fails, jump to the app image in the first
<azonenberg>
if ok, jump to second
<electronic_eel>
no, I mean the code in the bank itself. aren't all the jumps, function addresses and so on, linked to this exact flash address?
<sorear>
what if the code has a correct crc but is just buggy
<azonenberg>
but you can compile arm code to be relocatable
<azonenberg>
sorear: we can add a watchdog or something to reboot to the golden image if something bad happens
<electronic_eel>
why not have just the bootloader and one image in the stm32, and two in an external spi flash
<azonenberg>
the dual panel strategy i'm describing is how literally every commercial product i've looked at implements firmware updates
<electronic_eel>
then the bootloader can read the stuff via spi and flash it into the stm32 if necessary
<azonenberg>
and i've RE'd a *lot* of firmware updaters
<azonenberg>
it's probably half what i do at $dayjob
<azonenberg>
fwiw i'm personally a fan of having the fpga be the master of a system and then the mcu be a "state machine accelerator"
<azonenberg>
i.e. i really plan to have the stm32 be a scpi -> spi register write bridge
<azonenberg>
and tft -> ip config converter
<azonenberg>
tft+captouch*
<electronic_eel>
so you want to trigger fw updates for the stm32 via the fpga?
<azonenberg>
the stm32 can update itself because it's off in its own little world
<electronic_eel>
let's say the user decides something is wrong and he wants to flash the golden master image onto the stm32
<azonenberg>
My original concept for this scope didn't even *have* an mcu
<Degi>
Hm where can config data be stored? Does the STM have extra EEPROM or so? Or on the FPGA config mem?
<electronic_eel>
how would the user do that?
<azonenberg>
electronic_eel: typically this isn't something a user has choice over. the device always comes up to the latest firmware and if that fails to boot, it falls back to the golden master automatically
<azonenberg>
if you release a brick-firmware with a valid crc that doesn't work, better grab a jtag dongle
<azonenberg>
this is why you test before you release
<electronic_eel>
there is the case that there is a bug in the firmware or the firmware can't decide itself that it failed to boot
<azonenberg>
Yeah. And for now, the solution to that is jtag
<electronic_eel>
I think there should be a button or something the user can press to flash the golden master image
<azonenberg>
i guess we can have a jumper/button on the mainboard (internally) that lets you force a boot of the golden image
<azonenberg>
it won't *flash* anything
<azonenberg>
it will just skip the crc check and always declare the app image bad
<electronic_eel>
you just need to put the small extra spi flash and some button (reachable with a needle from the back or similar) for it
<azonenberg>
and force a fallback boot
<azonenberg>
no spi flash
<azonenberg>
still on die flash
<azonenberg>
the way these bootloaders normally work, pseudocode, is
<Degi>
Why would an extra SPI flash help anyways?
<azonenberg>
if(recovery mode enabled)
<azonenberg>
jmp flash_bank1
<azonenberg>
if(crc(flash_bank2) == crc_expected)
<azonenberg>
jmp flash_bank2
<azonenberg>
else jmp flash_bank1
<azonenberg>
the bank1 image need not be a fully functional application, it's ok if all it knows how to do is re-flash bank2
<azonenberg>
and bank1 will never be written after initial factory-time jtag loading
<electronic_eel>
ok, if we develop and link a special application that is only designed to work as bank1, then this would work
<electronic_eel>
I prefer to use a normal application build as the golden master
<electronic_eel>
and don't use 2 banks because of the absolute addressing problem
<electronic_eel>
I want my builds to not care if they are bank1 or bank2
<azonenberg>
well the other thing is though, normally most jumps on arm are relative anyway
<azonenberg>
i'm pretty sure all we'd have to do is -fPIC the compile
<electronic_eel>
so I put the builds in an external flash and the bootloader reads from the flash and writes into the flash of the mcu
<electronic_eel>
so I also get to use the full flash size of the mcu
<azonenberg>
yeah but this chip has 2 megabytes of flash. wtf are we going to put on this thing that needs >1 meg of code
<electronic_eel>
external spi flash size is very cheap compared to mcu flash size
<azonenberg>
honestly even a much smaller one would work, only reason i wanted this is that it has the LCD controller and enough ram for a framebuffer
<electronic_eel>
nice graphics for the http webserver mode?
<azonenberg>
but during cost optimization we can shrink
<azonenberg>
i still think a web server is totally pointless and redundant
<azonenberg>
the intended operating flow is to plug it in, if you want a static ip use the front panel to configure that
<azonenberg>
launch glscopeclient, connect to it, and be good
<Degi>
Hm so IP config can be stored on MCU flash?
<azonenberg>
once every few months, maybe run a cli firmware update tool
<azonenberg>
when and where does a web server fit into this flow?
<azonenberg>
Degi: the fpga will probably have an i2c eeprom with a preprogrammed mac address attached to it
<electronic_eel>
Degi: you could reserve some space in the mcu flash for ip config
<azonenberg>
there's enough space on that for ip config, which makes more sense as tcp/ip will be done in gateware
<electronic_eel>
a i2c eeprom would be the other option
<Degi>
Or on the gateware flash
<azonenberg>
i like eeproms for small config like IP settings because they're byte writable
<azonenberg>
eliminates a lot of the annoyances with page level flash access
<azonenberg>
and the alternative to using a mac addr eeprom is either to buy an OUI and program my own mac addresses somewhere (expensive) or use a random locally assigned mac (not ideal)
<Degi>
WE could use FRAM
<Degi>
Whats a OUI?
<azonenberg>
Organizationally Unique Identifier, the first 3 bytes (roughly) of a mac address
<azonenberg>
you can buy an at24mac402-mahm-t for 33 cents on digikey @ qty 1
<azonenberg>
there is really no reason not to do this
<electronic_eel>
yes, buying a i2c eeprom with oui on it is usually the best option for small scale stuff
<Degi>
Lol or a 1 wire device, they automatically have that
<azonenberg>
256Kx8 eeprom. Contains a 128-bit serial number, a 48-bit mac address, and 256 bytes of user programmable eeprom
<electronic_eel>
no, not oui, eui
<Degi>
Hm thats 256x8 not 256k
<azonenberg>
yes
<azonenberg>
256 bytes
<azonenberg>
but random access via i2c. all we need to store is an IP address, gateway, and subnet mask
<Degi>
(I mean you wrote 256K heh)
<azonenberg>
no need for DNS config as we won't ever need to resolve names clientside
<azonenberg>
oh sorry
<Degi>
Nvm
<electronic_eel>
dns server name, ntp server name
<azonenberg>
electronic_eel: now you want ntp on the scope?
<electronic_eel>
yes, later ptp
<electronic_eel>
but start with ntp
<electronic_eel>
to at least get some idea of realtime for the trigger point
<Degi>
I think the MAC should be user changeable
<azonenberg>
Degi: why?
<Degi>
Why not
<azonenberg>
what possible purpose is there for that
<azonenberg>
i have never seen an embedded device that allows this
<electronic_eel>
Degi: if someone wants to do this, they have to solder another i2c eeprom on
<azonenberg>
electronic_eel: the ksz9031 doesn't have 1588 support internally, so we'd probably only get timing on the 1G interface to the RGMII boundary
<azonenberg>
then for 10G we'd be limited also because of variable propagation delay on the XAUI bridge
<azonenberg>
for the higher end scopes with 10g serdes on the fpga and a soft pcs, much easier
<electronic_eel>
oh, didn't look that deep into the datasheet for the phy
<electronic_eel>
I think if you can get accurate realtime in the 100 µs range it would be good enough for many applications
<electronic_eel>
if you really want cycle and phase accurate timing, then you have to do much more effort than 1588
<azonenberg>
i mean, honestly? on a normal gig/10g lan? ntp is probably good for << 1 ms accuracy
<azonenberg>
at least if you only care about skew to the local ntp server
<azonenberg>
for my purposes, absolute trigger time doesn't matter
<azonenberg>
i care about deltas
<azonenberg>
time between events is important, time of the first is not
<electronic_eel>
for slower stuff, like graphs over measured values, I care about absolute times. because I want to be able to compare them to logfiles and similar stuff
<azonenberg>
anyway, i plan to provide some uncommitted gpios between mcu and fpga in case needed by future firmwares
<electronic_eel>
that runs on another instrument
<azonenberg>
of course, but at that point ntp or even just "pc pushes current time_t over scpi" is good enough
<Degi>
Hm cant we just sync the triggers and measure time since trigger?
<electronic_eel>
that is why I thought we should start with ntp
<azonenberg>
Which is what i plan to do in initial firmware. when a client connects, it will push current time to the scope, there will be an uncompensated round trip delay
<azonenberg>
ntp will be added next
<azonenberg>
but pushing time is stupidly easy to do, just a couple of lines of code to write followed by a free running clock
<azonenberg>
it will get accuracy to probably a ms or two
<azonenberg>
at least on a lan
<azonenberg>
On my lan, round trip time from my workstation to one of my fpga boards is in the 30 μs range
<azonenberg>
with occasional noise spikes from interrupts on the pc side pushing that up to a bit under 100 μs worst case
<electronic_eel>
roundtrip isn't the issue, roundtrip jitter is
<azonenberg>
how much jitter do you have on your lans?
<electronic_eel>
don't have a measurement at hand, usually the ntp measures this and corrects for it
<electronic_eel>
that is what ntp is for
<Degi>
Hmm cant the trigger input be used to sync multiple device times
<Degi>
And then just add some TCXO or something idk
<azonenberg>
there will still be a fixed offset between them
<azonenberg>
anyway, i want to keep initial firmware simple then add features
<azonenberg>
My proposal is uncompensated push of time to start. this should get sub millisecond accuracy
<azonenberg>
on a lan
<azonenberg>
i just did a test getting 186 μs average *through a router* as well as multiple switch hops to the fpga board in the other room
<electronic_eel>
yes, the scope should run first, not wait for the perfect timing solution to be finished in two years
<azonenberg>
then add NTP after that, then ptp later
<azonenberg>
have a timebase, have a means of setting it
<azonenberg>
that means can be swapped out in a modular fashion
<azonenberg>
i mean, if we really want ultimate timing accuracy...
<azonenberg>
we could add a sma input on the back of the scope for a gps pps signal
<Degi>
We could use trigger for synching
<azonenberg>
combine this with the 10 MHz external refclk input
<azonenberg>
use NTP to get time to the nearest second, then PPS for ultra fine sync
<Degi>
Does GPS broadcast time?
<azonenberg>
It would cost almost nothing to add an extra SMA + comparator to the back of the scope, we can DNP it if not needed
<azonenberg>
Degi: that's how gps works :p
<Degi>
In germany we have this 77.5 kHz or so signal thats very accurate
<Degi>
I mean yeah so we could just use that
<azonenberg>
the tl;dr is you have a bunch of atomic clocks floating around in orbit
<azonenberg>
and you triangulate position by measuring propagation delay to each
<Degi>
You know your position relative to them and can calculate the absolute time
<electronic_eel>
you should broadcast the nmea from the gps unit somehow, because the timing gps units tell you the diff between the pulse and the real second
<Degi>
Yeah basically undo the prop delay
<Degi>
nmea?
<azonenberg>
electronic_eel: i've been talking to LeoBodnar about making a combination unit
<azonenberg>
he has a gps stratum 1 ntp server with pps, and a gpsdo
<electronic_eel>
nmea is the protocol you use to talk to gps units
<azonenberg>
they are currently separate products
<azonenberg>
i want him to merge them
<azonenberg>
so you get ntp, pps, and frequency reference. Adding some means of accessing the full nmea string would be nice too
<electronic_eel>
yes, merging them makes sense
<Degi>
Can we add a GPS receiver and a battery and a GSM module to keep track of when somebody kidnaps the scope?
<azonenberg>
lol
<azonenberg>
My plan is to build a lab-wide frequency distribution system that integrates to one of those units via pps/refclk input connectors, jitter filters and mutliplies with a pll, and outputs precision timebase to various instruments in the lab
<electronic_eel>
so the extra sma input would be a nice idea, at least as footprint
<azonenberg>
Yeah
<azonenberg>
sma + comparator since the fpga lvds input isnt as clean as a proper comparator
<azonenberg>
do automatic 50% thresholding: ac couple the input and compare to zero
<electronic_eel>
yes
<azonenberg>
maybe with a dc bias so we can run single supply
<azonenberg>
we'll need this exact circuit on the ext refclk input
<azonenberg>
so just have one going to the fpga and one to the pll
<Degi>
Woo my PCBs seemingly arrived in EU distribution center
<azonenberg>
and optionally DNP this one
<Degi>
PoE
<electronic_eel>
PoE for the scope? no way
<Degi>
:sadface:
<azonenberg>
honestly, if i was only doing 1g ethernet? i'd seriously consider it
<azonenberg>
but i expect the 1g to be an afterthought for people who don't have a good cable plant
<Degi>
Hm k
<azonenberg>
and the primary interface to be optical
<Degi>
We can have 10G over copper
<azonenberg>
and optical poe isnt really a thing for obvious reasons
<azonenberg>
no, we cannot
<azonenberg>
have you tried to buy 10Gbase-T PHYs?
<Degi>
Will it just have a 12 V wall wart?
<Degi>
Not yet
<azonenberg>
they basically don't exist
<Degi>
Hmm thats why nothing has 10G copper...
<azonenberg>
you need to be broadcom's ceo's daughter's boyfriend or something to get one
<Degi>
lol
<azonenberg>
Or you can just plop down a SFP+ cage and be done
<electronic_eel>
10Gbase-T is bad, much too power hungry, too expensive, has more latency
<azonenberg>
i have never seen a datasheet for a 10gbase-T PHY
<Degi>
Hmm why isnt optical PoE a thing? Like just add a few VCSELs on one side and a solar panel on the other
<azonenberg>
i have never seen a distributor openly selling them
<Degi>
Or a mini steam turbine
<azonenberg>
they have terrible latency, they're expensive, they eat power, they're slow
<azonenberg>
and they cant even run over most copper cable plants because it's so picky about cable quality
<azonenberg>
if you have to upgrade all of your cat5e to cat7 anyway, why not pull multimode instead?
<azonenberg>
That was my rationale when building out my lab. I pulled cat5e and OM4
<azonenberg>
as far as i'm concerned, baseT dead ended at gigabit
<Degi>
Hmm multimode? Doesnt that have lower bandwidth?
<Degi>
Or a lower length-bandwidth product
<azonenberg>
Degi: how big do you think my house is?
<Degi>
Idk? 10 km end to end?
<azonenberg>
lol
<azonenberg>
Because 40Gbase-SR4 will do 150 meters over OM4
<Degi>
Hm well
<Degi>
Can you use singlemode fiber for data storage
<Degi>
With pingfs or how that was called
<azonenberg>
as will the nonstandard 40Gbase-SR2-BIDI which runs over a single duplex fiber with CWDM instead of four fibers each way
<azonenberg>
100Gbase-SR2-BiDi will do 100G over a single duplex OM4 fiber for 100m
<azonenberg>
and 70m over OM3
<electronic_eel>
so with OM4 you have a good solution for the next years to come
<Degi>
Like if you have 40 G over 10 km you have approx 2 Mb one way
<azonenberg>
electronic_eel: exactly
<azonenberg>
I saw no reason to do OM5 (expensive and not widely available preterminated) or singlemode
<azonenberg>
right now i am mostly gigabit copper with a handful of 10G links, and the endpoints to deploy up to four 40G links via cabling that isn't yet installed (my desk only has one duplex fiber to it, i haven't pulled the rest yet)
<electronic_eel>
the sfp-modules for singlemode are more expensive, no need for that within a single building
<azonenberg>
but once fully installed i could hypothetically pull four 100G links to every bedroom / desk / lab bench
<azonenberg>
the cable plant is not going to be a limitation, ever :p
<azonenberg>
and i suspect 400G will be viable over OM4 for shorter runs, like within the lab. maybe not the living room
<electronic_eel>
yeah, you won't sleep well if you don't have a 100G link next to your pillow ;)
<azonenberg>
in the extraordinarily unlikely event that i need more bandwidth it's all in conduit and cable tray
<azonenberg>
so i could easily pull OM8 in 2050 if the need arises
* Degi
has 5 G(Hz) under her bed
<Degi>
Keeps the corona away
<electronic_eel>
oh, wasn't it the other way round, like corona being caused by 5G?
<electronic_eel>
but I also read it was spread because of a feud between the illuminates and the reptiloides
<Degi>
Not if the 5G is strong enough
<Degi>
It kinda gets disinfecting when the blackbody radiation of nearby absorbing effects gets into the UV region
<electronic_eel>
yeah, if the body gets black due to 5G power, then a virus will get fried too
<azonenberg>
electronic_eel: i want one of those "team chemtrail" challenge coins
<Degi>
Hmm I calculated that this pulsed laser should be able to get to 1-2 keV of blackbody peak radiation if focused well enough (below tens of µm²)
<electronic_eel>
what is a team chemtrail challenge coin?
<electronic_eel>
do you get that when you cook up some new conspiracy theory?
<azonenberg>
lol some website for pilots was selling them a while ago
<Degi>
Lol
<azonenberg>
along with "chemtrail technician" shoulder patches
<electronic_eel>
ah, cool
<Degi>
I have a "contains chemtrails" sticker on my bottle
<azonenberg>
no "warning, contains dihydrogen monoxide"?
<electronic_eel>
I would put some chemtrail warning on a fuel vehicle on an airport
<azonenberg>
lol
<azonenberg>
The other thing i really want is a t-shirt with a california prop 65 warning on it
<azonenberg>
"this person contains chemicals known to the state of california to cause cancer"
<electronic_eel>
hehe
<Degi>
"this person is known to the state of california to cause cancer"
<Degi>
Hm why dont they specify which institution though? Doesnt california have its own mini CDC or so?
<azonenberg>
They have a mind of their own. one of many reasons i won't live there
<azonenberg>
(interestingly, cocaine is on the prop 65 list)
<Degi>
Is dihydrogen monoxide on the list?
<azonenberg>
Surprisingly, no
<electronic_eel>
cool, so you can sue your dealer if he doesn't print the prop 65 warning on your cocaine ;)
<Degi>
Coal power plants?
<Degi>
Lol
<Degi>
Mini baggies with prop 65 warning
<azonenberg>
electronic_eel: marijuana is on the list too
<Degi>
Hash bricks with prop 65 warning laser engraved
<azonenberg>
Mustard gas (i think cancer isn't your biggest problem around that...)
<electronic_eel>
nuclear warheads?
<azonenberg>
But estrogen, progesterone, and testosterone are on the list
<sorear>
chronically?
<azonenberg>
So literally any person contains chemicals known to the state of california to cause cancer
<miek>
the great part is that the thing doesn't need to be on the list, you can just slap the warning on anything :D
<Degi>
Is water on the "causes 100% death rate after exposure, effects may take years to manifest" list
<azonenberg>
Degi: lol
<azonenberg>
so is oxygen
<Degi>
Oxygen peroxide
<azonenberg>
somewhat surprisingly, uranium is *not*
<sorear>
are elements chemicals?
<azonenberg>
Thorium dioxide is
<azonenberg>
sorear: metallic lead is on the prop 65 list
<azonenberg>
as are both metallic nickel and all nickel compounds
<Degi>
Wait you can cryogenically react O3 with atomic hydrogen and then react that to H2O4?
<azonenberg>
so is any enig plated pcb a carcinogen in california?
<electronic_eel>
probably. also the bpa in the fr4
<Degi>
Hmm it apparently is possible to make ozone peroxide for a short time
<Degi>
Does fr4 necessarily contain BPA?
<electronic_eel>
don't think you can make epoxies without having some bpa residue
<azonenberg>
silica dust is on the list, so if the board wasn't cleaned perfectly after cutting
<Degi>
(And how bad is that? I kinda got that on my hands a few times lol)
<azonenberg>
that's another one
<sorear>
"nickel (soluble compounds)" would include a good chunk of extant life but I don't think humans
<sorear>
this is a weird list
<sorear>
good to know that uranyl acetate is safe though
<azonenberg>
lol
<Degi>
Sure haha
* Degi
pours a few liters of enriched uranyl acetate into a bottle and hands that to whoever is responsible for making that list
<Degi>
Disinfecting lamp
<azonenberg>
afe test boards are in :D
<azonenberg>
will be assembling after i'm done with work for the day
<sorear>
other things on this list humans make: acetaldehyde, CO, isoprene, retinoic acid, thiouracil
<sorear>
azonenberg: page 19, "radionuclides"
<sorear>
which raises questions of its own
<sorear>
did pepto-bismol have to add a warning in 2003? (did they have an unrelated one before?)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg>
Sooo i am thinking, for the stm32 on the afe test board
<azonenberg>
i might implement a subset of the actual scpi command stack for the real scope