<_whitenotifier-f>
[scopehal-docs] azonenberg 4251ebf - Merge pull request #9 from nshcat/win32-building Win32 building
<_whitenotifier-f>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfNja
<_whitenotifier-f>
[scopehal-docs] azonenberg 0452f48 - Fixed typo "me make use of" -> "we make use of"
<Katharina>
Right now, users still have to keep using MSYS to start it, but thats just until i fixed my script that grabs the dependencies. The binary is a fully native win32 one. So in the end, we could offer binary packages, and the users wouldnt need MSYS2 at all anymore
<azonenberg>
katharina: Makes sense. Yes, i think that, with a nice installer and everything, is the end goal
<azonenberg>
but compiling is a good start
<Katharina>
so what my script does is use objdump to look at what the binary links to, and walking that tree and flatten it into a simple list of dlls
<Katharina>
the issue currently is that there is a weird pseudo dependency that doesnt even exist
<azonenberg>
Lol
<azonenberg>
katharina: btw are you completely unable to go into the office and test with one of the Rigols? Not sure what the virus situation/lockdown is like by you
<Katharina>
azonenberg: I might be able to go into the lab next monday
<azonenberg>
in our case my employer is working nearly 100% remote but people are allowed to go to the office (with manager approval) to pick up tools from the lab to take home etc
<azonenberg>
So if you can get permission to take one of the rigol scopes home to test on, that would be ideal
<Katharina>
i ordered a faceshield today, which is one of the new policies. maybe i can even visit earlier when it arrives
<azonenberg>
yeah we're required to wear masks when in the office and gloves, while not required, are strongly encouraged
<azonenberg>
i haven't been to the office since March because I haven't had a need to, my lab at home is more than capable
<azonenberg>
this is an old photo before i got the solder fume extractor and a few other upgrades
<azonenberg>
And there's about 13 km of water between me and the office, and the ferry boat seems like a good place to avoid right now :p
<azonenberg>
if i lived close enough i could walk/bike/drive and not have to take public transit i'd consider it if i needed to
<Katharina>
yea I haven't built up any significant number of devices in my home lab tbh
<Katharina>
ill get a personal rigol next month
<azonenberg>
nice. Same model you have at work or something else?
<Katharina>
most likely yes.
<Katharina>
just familiarity
<azonenberg>
if you can get all three in the same place at once i'd love to hear results
<Katharina>
ohhh boy, combining all the channels
<azonenberg>
You'd need an RF splitter to couple the trigger from the primary to the two secondaries, but those are cheap enough (SMA/BNC T fittings are not impedance matched so probably good to avoid for this purpose)
<azonenberg>
We've never tested with more than two scopes
<azonenberg>
the code was written to scale arbitrarily but a first attempt to try with three would be valuable feedback
<Katharina>
you know what would be interesting? Whether the 3x 16 logic analyzer channels could be combined
<Katharina>
that would be 48 channels
<azonenberg>
Once degi (or you) implements support for the logic probe, then yes
<azonenberg>
there's no internal distinction between analog and digital channels for most of the architecture
<Katharina>
yep
<azonenberg>
you will i believe need to use analog signals for the synchronization, and i don't think the sync feature will work for pure LAs that do not have analog channels yet
<azonenberg>
although i could improve that later on
<azonenberg>
right now it relies on cross-correlation, which only really makes sense for analog values
<azonenberg>
but once synced you can use all of the channels
<azonenberg>
We may need to do some UI work to figure out how to USE that many channels, lol
<azonenberg>
but if you do protocol decodes or merge them into buses, then hide the original channels, the UI will get much less cluttered
<Katharina>
yea, i do the same in pulseview
<Katharina>
azonenberg: What is the official link to the manual build?
<azonenberg>
There is no official mirror
<azonenberg>
i was going to probably set up a github.io page or something at some point
<azonenberg>
but it's not official, given that it's in the "temp" directory
<azonenberg>
it's just a way for me to share drafts with people etc
<Katharina>
would you be alright with me linking that in the scopehal-cmake README for now?
<azonenberg>
eh, i guess
<azonenberg>
if i start seeing bandwidth problems we can move it elsewhere
<azonenberg>
that server is on a DOCSIS link with about 10 Mbps of upload :p
<Katharina>
I'm going to set up a build server for windows CI on my server aswell
<Katharina>
I just want to make sure Windows supports stays working and that no change will stop it from compiling
<Katharina>
(which sometimes just happens when not many of the devs use Windows)
<azonenberg>
Great, go for that
<_whitenotifier-f>
[scopehal-cmake] nshcat opened pull request #16: Update README.md to include Windows build instructions - https://git.io/JfAea
<_whitenotifier-f>
[scopehal-cmake] azonenberg closed pull request #16: Update README.md to include Windows build instructions - https://git.io/JfAea
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JfAei
<_whitenotifier-f>
[scopehal-cmake] nshcat 30a9d9d - Update README.md to include Windows build instructions
<_whitenotifier-f>
[scopehal-cmake] azonenberg 7e30974 - Merge pull request #16 from nshcat/patch-1 Update README.md to include Windows build instructions
<Katharina>
I forgot yesterday to push the changes to the logging library build, I created a PR for that
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfAJa
<azonenberg>
katharina: Can you look at scopehal-cmake:#1 and, if monochroma/antikerneldev's proposed solution works (relative paths) send PRs to all relevant repos to use relative paths for submodules?
<azonenberg>
i.e. developers will clone via ssh and be able to do ssh pushes but anonymous clones via https will still work
<azonenberg>
this has been open for a year or more and i havent had time to touch it lol
bvernoux has joined #scopehal
Katharina has quit [Ping timeout: 240 seconds]
Katharina has joined #scopehal
<Katharina>
azonenberg: will do
<_whitenotifier-f>
[starshipraider] azonenberg pushed 2 commits to master [+0/-0/±21] https://git.io/JfAKY
<_whitenotifier-f>
[starshipraider] azonenberg 4f01f7c - Fixed missing AA16 ground on U2C symbol
<_whitenotifier-f>
[starshipraider] azonenberg 022eedf - Continued schematic review. Added footprints for C1-C282.
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JfAiI
<_whitenotifier-f>
[starshipraider] azonenberg 5a6d511 - Assigned footprints for all capacitors
<Katharina>
azonenberg: I implemented https://github.com/azonenberg/scopehal-apps/issues/86 because this is important to me personally, and I replaced the serial numbers with "XXX". Do you want me to do something more involved, like just censor the last N characters. or is this fine?
<azonenberg>
actually i would do the opposite, censor all *but* the last say 2
<azonenberg>
so if you have multiple scopes you can tell them apart
<azonenberg>
like they do with credit card numbers
<azonenberg>
the first few are the bank, in between is the account number, then at the very end is a checksum. and receipts etc normally print the last four
<azonenberg>
scope serial numbers are shorter so i'd print the last 2
<azonenberg>
This ties into a bigger issue, though, we need a preferences framework
<azonenberg>
to persist the setting across runs
<azonenberg>
Settings should be serialized to a YAML file in ~/.scopehal/preferences.yml on Linux, and a reasonable choice of location on Windows
<azonenberg>
then loaded with yaml-cpp at startup
<azonenberg>
rather than it being under the view menu, i'd put it under setup|preferences and pop up a dialog
<azonenberg>
And the preference should be called "hide serial number", not "obfuscate". obfuscate implies rot13ing or something
<Katharina>
got it
<azonenberg>
That's why i didn't implement this issue yet, it wasn't quite so straightforward :) But if you want to go do it, I'll be happy - it needed to happen
<azonenberg>
Just a question of when
<Katharina>
its more modern to put it in ~/.config/scopehal tho according to XDG, so i'd put it there tbh
<azonenberg>
That's fine. But would plugins go there too or what?
<azonenberg>
right now we look in ~/.scopehal/plugins/
<Katharina>
hm
<Katharina>
the reason is to unclutter ~/
<Katharina>
so i would say so, yes
<azonenberg>
plugins in .config seems a bit awkward though
<Katharina>
indeed it does
<azonenberg>
Let me file a separate ticket for a preferences framework
<azonenberg>
Just so we can disambiguate PRs etc
<Katharina>
plugins should go into .local/share tbh
<Katharina>
sure. i feel interesting in doing the settings systems
<Katharina>
*interested
<azonenberg>
Fine by me. Send a PR with that change then, also add some documentation to scopehal-docs regarding that plus Windows plugin stuff
<Katharina>
got ya
<azonenberg>
i don't think we have any documentation about plugins at all yet
<azonenberg>
so as long as you're changing where it looks, you should write docs with the new info
<Katharina>
yep
<azonenberg>
Regarding the pref framework i'm thinking of having prefs of a few different types, starting out probably strings, doubles, and bools
<azonenberg>
internally a key-value store using a std::map or similar
<azonenberg>
then have various UI classes reference an instance of PreferencesManager within the OscilloscopeWindow, then when the app is closed save changed prefs
<azonenberg>
sound reasonable?
<Katharina>
yes
<Katharina>
i would personally also save when the preferences dialog is closed, so that crashes dont revert changes
<azonenberg>
Agreed, that makes more sense
<Katharina>
i would assume gtkmm has such an event
<azonenberg>
Then in the UI, use something similar to the ProtocolDecoderDialog to dynamically create a dialog that lists each preference along with an appropriate widget to modify the value
<Katharina>
for the initial config (when none exists) ill just do a method that populates the manager with sane defaults for now
<Katharina>
that should suffice for now
<azonenberg>
Also given how much work you've been doing i think it's time I officially added you to the project. You've been doing so much stuff it's more than time i started assigning tickets to you officially lol
<Katharina>
^^
<azonenberg>
I think the OscilloscopeWindow constructor should create a list of preferences with names, default values if not in the config, and maybe some help text
<azonenberg>
Consider the case also of preferences being added to a user who has an existing config without it
<Katharina>
yea, a nice description that could be shown in a tooltip if the user hovers over it in the prefs window
<azonenberg>
so defaults will be applied per pref, not just if there's no prefs file
<Katharina>
azonenberg: good point
<azonenberg>
ok invites sent for each repo. For now, consider this probationary access. You can assign tickets to yourself and work on them, and mark tickets closed in commit messages
<azonenberg>
But don't push to master until i've had a chance to review your changes
<azonenberg>
If you send a PR with changes, you can merge it yourself once I verbally approve
<Katharina>
yea I wont just push to master, dw
<azonenberg>
Feel free to make private dev branches in the official repo
<azonenberg>
Let me know when you've accepted the invites and i have a few tickets to assign to you
<azonenberg>
i can't do it until you accept
<Katharina>
sure
<Katharina>
i wanted to make a ui-dev branch, and then branches off that for the individual parts. Id still like you to review them, merge them into ui-dev, and when the whole preferences thing is done merge that to master
<azonenberg>
Makes sense
<azonenberg>
As a general rule, potentially breaking changes should be done in a private branch until anything likely to break is tested and confirmed OK
<Katharina>
got it
<azonenberg>
I'm OK with incremental changes being added directly to master as long as they're verified locally and either fix bugs or at least are not known to add new ones
<azonenberg>
adding new incomplete functionality to master is OK as long as nothing that worked before the commit stops working
<azonenberg>
basically the functionality after each commit to master should be a strict superset of the previous functionality
<azonenberg>
Once we get closer to a formal version 1.0 release we'll start thinking about feature freezes and making master more stable, ensuring all documentation is up to date, etc. I don't think the project is quite mature enough for that
<Katharina>
yeaa
<Katharina>
thats a thing for the future i think, too
<azonenberg>
My general rule is that I call the version 0.x until it's sufficiently stable and well documented that I can reasonably expect a person who is not an active developer to be able to use it without hand-holding
<azonenberg>
That is the definition of 1.0
<Katharina>
yep
Katharina has quit [Quit: Leaving]
<azonenberg>
from then on feature upgrades are point releases, and the major revision is incremented if there are significant changes that either break compatibility in some way, or make significant changes to the user interface that would potentially require a user to take time to adapt to
Katharina has joined #scopehal
<azonenberg>
(06:10:42) azonenberg: from then on feature upgrades are point releases, and the major revision is incremented if there are significant changes that either break compatibility in some way, or make significant changes to the user interface that would potentially require a user to take time to adapt to
<azonenberg>
lain, degi, electronic_eel, Pretzel4Ever: FYI i got a budgetary price from Multech for the MAXWELL PCB. Just based on projected board dimensions and specs, so subject to change once the design is done
<_whitenotifier-f>
[scopehal] azonenberg added user nshcat - https://git.io/JfNTg
<_whitenotifier-f>
[scopehal-cmake] azonenberg added user nshcat - https://git.io/JfNTg
<azonenberg>
for five bare boards it's $500 in setup costs, then $285.50 per board (total $1927.50) assuming RO4350B on all layers
<_whitenotifier-f>
[scopehal-apps] azonenberg added user nshcat - https://git.io/JfNTg
<azonenberg>
This drops to $85.50/board (total $927.50) assuming FR408HR on all layers
<azonenberg>
If we do mixed Rogers and FR408, the price will be somewhere in between
<Katharina>
azonenberg: accepted the invites
<azonenberg>
The good news is that Er of FR408HR and RO4350B are very close, so we can use similar design rules on each
<azonenberg>
I'm going to do some simulations once i finish the schematic review to figure things out. I think a mixed stackup makes sense, I at least want the 10gbit traces on rogers but we can probably get away with 408HR on the slower stuff
<_whitenotifier-f>
[scopehal-cmake] azonenberg assigned issue #1: Change .gitmodules url in order to allow clone from anonymous user - https://git.io/fjZb6
<_whitenotifier-f>
[scopehal-apps] azonenberg assigned issue #86: Add preference setting to partially redact instrument serial number in title bar - https://git.io/JfnyF
<azonenberg>
Katharina: ok that should be enough stuff to keep you busy for a bit? :)
<_whitenotifier-f>
[scopehal-cmake] 9names forked the repository - https://git.io/JfA1t
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #118: When starting glscopeclient with no arguments, allow a file to be opened for offline analysis instead of connecting directly to an instrument - https://git.io/JfA1Y
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #118: When starting glscopeclient with no arguments, allow a file to be opened for offline analysis instead of connecting directly to an instrument - https://git.io/JfA1Y
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #119: Allow "connect to scope" dialog to be re-launched once a session is active - https://git.io/JfA1s
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #119: Allow "connect to scope" dialog to be re-launched once a session is active - https://git.io/JfA1s
<Katharina>
azonenberg: yea :p
Katharina has quit [Ping timeout: 246 seconds]
Katharina has joined #scopehal
<Katharina>
Ok, IRC and spotty mobile networks don't mix well it seems
<azonenberg>
yeah a lot of folks here in that situation have set up bouncers on a server with a more reliable connection
<azonenberg>
znc seems to be popular although i havent used it myself as i have a desktop on a stable cable connection so i just use that as my irc box
<monochroma>
screen/tmux + irssi/weechat ftw
<Katharina>
thanks, I'll try znc I think
<azonenberg>
monochroma: so far i've found three bugs during the design review that would have made the board not work, lol
<azonenberg>
and i'm just getting started
<azonenberg>
although only one of the three was something i "should" have found based on where i am in the checklist
<azonenberg>
the other two were missing pullups i just happened to notice, but hopefully would have found anyway later in the process
<monochroma>
:o
<azonenberg>
The bug i actually found by working through the list was a missing ground pin on the FPGA
<azonenberg>
There are grounds on pins A1, A6, A16, AA6, and AA16 (among others)
<azonenberg>
the AA16 ground was missing
<azonenberg>
so i would have floated that pin
<monochroma>
eh hehehe, that's one of those nasty ones that would PROBABLY be fine, but maybe cause some wonk issues with higher current stuff (if there were a million other grounds like most FPGAs)
<azonenberg>
yeah exactly
<azonenberg>
this is why i do a full pin by pin verification of every new schematic symbol
<azonenberg>
this checklist keeps proving its worth
<azonenberg>
i also found a bug in a micron datasheet
<azonenberg>
four resistors going to the wrong rail that probably would have been fine because they were supposed to be DNP'd anyway
<azonenberg>
but had i decided to put hysteresis there it wouldn't have worked
<azonenberg>
and then the front panel LCD backlight had reversed polarity
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 4 commits to master [+0/-0/±4] https://git.io/JfAH9
<_whitenotifier-f>
[scopehal-cmake] 9names 25fbf5c - Add FFTS include suffix to existing include search paths
<_whitenotifier-f>
[scopehal-cmake] 9names 69afe1d - Add default name for ffts static lib to the list of names to search for in CMake
<_whitenotifier-f>
[scopehal-cmake] 9names 9ac8ba7 - Remove common suffix from include paths. This also means the suffix is applied to default include paths, so can find FFTS in MinGW without any help
<_whitenotifier-f>
[scopehal-docs] azonenberg closed pull request #11: Allow building with Ninja, simplify MinGW build instructions - https://git.io/JfAHg
<_whitenotifier-f>
[scopehal-docs] azonenberg pushed 3 commits to master [+0/-0/±4] https://git.io/JfAHx
<_whitenotifier-f>
[scopehal-docs] 9names 1d0b9f3 - Replace globbed DEPENDS list with an explicit one, so that CMake generators that don't support globbing (eg Ninja) can successfully build docs
<_whitenotifier-f>
[scopehal-docs] 9names 3bcea2a - Remove manual copying in MinGW in favor of setting a sensible install prefix, and using make install. Note that this requires the ffts cmake improvements before scopehal can be built like this
<_whitenotifier-f>
[scopehal-docs] azonenberg 481e84d - Merge pull request #11 from 9names/simplify_mingw_build_instructions Allow building with Ninja, simplify MinGW build instructions
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfAQe
<_whitenotifier-f>
[scopehal-apps] azonenberg assigned issue #72: Add preference settings for how much metadata to put in .scopesession files - https://git.io/Jvga7
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #30: Allow multiple top level windows with waveforms in them - https://git.io/JfAQO
<azonenberg>
monochroma: SFP+ to SMA boards expected to come today
<azonenberg>
i'll either build them today or have jes make them tomorrow (she's coming tomorrow evening to build the MEAD boards)
<azonenberg>
oh sorry wait wrong tracking number
<azonenberg>
that's the v0.9 probes
<azonenberg>
sfp to sma boards are still at fab
<azonenberg>
Too many boards in the pipeline :p
<azonenberg>
but i ordered the sfp boards two days after the probes so they should be coming by later this week i'd estimate
<monochroma>
awww, got my hopes up
<azonenberg>
also just found another missing thing in the schematic
<azonenberg>
my digikey cart has four 40mm fans in it, but i don't have fan headers in the sch yet
<azonenberg>
i may not need all four but i figure better to have more pwm channels and not use them
<azonenberg>
So i need to go slap some four-pin fan headers down on the board. And probably run those off the stm32, which is basically going to be acting like a BMC/EC for the system
<azonenberg>
Also i think i have enough pins to run a RMII interface between the kintex and the stm32
<azonenberg>
if i can do that without losing any other important peripherals i'll try and do that
<azonenberg>
just for flexibility down the road
<azonenberg>
i dont actually need it
Katharina has joined #scopehal
<Katharina>
I love the build system changes that were just merged
<azonenberg>
Katharina: improvement?
<azonenberg>
no idea who 9names is, but they looked good and didn't break the linux build
<monochroma>
CIA plant
<azonenberg>
So i figured you'd let me know if they helped or broke something on windows :P
<monochroma>
XD
<Katharina>
azonenberg yea, good improvements for the windows build
<Katharina>
Beware of backdoors monochroma :p
* azonenberg
waters the CIA plant so it grows big and strong
<azonenberg>
seriously this last month or so has been amazing, several pretty active contributors getting involved
<azonenberg>
and lots of major improvements at all levels of the project
<azonenberg>
also he's not in the channel right now but i got an update from ziggggggy at lecroy
<azonenberg>
He's working on some tools that will access their raw COM APIs and expose a more efficient network interface for remotely downloading waveforms that should improve performance
<azonenberg>
apparently management likes the idea and is open to open sourcing it
<azonenberg>
this would be a tool that runs on the instrument and provides an alternative network API vs the standard MAUI SCPI stack
<monochroma>
wonder what the performance delta is going to be like
<azonenberg>
it probably wouldn't entirely replace the MAUI remote interface, it would be an accelerated waveform download stream only and you'd use normal scpi commands for configuration and status
<azonenberg>
Don't know yet, i dont think he has it to the point it's testable
<azonenberg>
But it's another related project in the pipeline
<monochroma>
no MAUI, just a screensaver with more comishioned anime artwork, animated to be doing adorable things that are scope related
<Degi>
Hmh yes we can use the FR stuff on power layers etc
<Degi>
How many layers is the budget for?
<Degi>
Oh yes can we add a screensaver to xscreensaver where it shows a scope trace or xy plot
<azonenberg>
lolol
<azonenberg>
monochroma: dont tempt me
<monochroma>
azonenberg: doooo ittttt
<azonenberg>
monochroma: well to start
<azonenberg>
i actually am having another artist from that same studio draw some new icons for the toolbar
<azonenberg>
no there will not be cute 24px high anime girls on the toolbar
<Degi>
Oh nice
<azonenberg>
but we are getting professionally drawn toolbar icons
<Degi>
Can we have a furry paw point at the trigger level
<azonenberg>
lolol
<monochroma>
azonenberg: have them done in the SGI icon set style!
Katharina has quit [Read error: Connection reset by peer]
<monochroma>
am i crazy or is that vector graphics isometric line art style not awesome?
<azonenberg>
It looks cool and retro but not a good fit for scopehal :p
<monochroma>
liessss
<_whitenotifier-f>
[scopehal-cmake] nshcat created branch gui-dev https://git.io/JfAAK
<_whitenotifier-f>
[scopehal-cmake] nshcat created branch gui-dev - https://git.io/JfAA6
Katharina has joined #scopehal
<Katharina>
azonenberg: Do you want preferences to be nestable? Like being able to group them together like `view::hide_serial`
<electronic_eel>
azonenberg: about RMII to the STM32 - I really like the idea, because this way you could easily load off stuff like DHCP or NTP to the STM32
<electronic_eel>
but be careful, because the STM32F7 have a nasty bug in their RMII silicon
<electronic_eel>
basically sometimes their clock is initialized the wrong way and you receive just gibberish
<electronic_eel>
as workaround they suggest to do some crc monitoring and if you get too many errors, do a reset
<electronic_eel>
I do not like that at all
<electronic_eel>
so try to use MII as this is not affected
<_whitenotifier-f>
[scopehal-apps] nshcat created branch gui-dev https://git.io/JfxvP
<_whitenotifier-f>
[scopehal-apps] nshcat created branch gui-dev - https://git.io/JvExD
<_whitenotifier-f>
[scopehal-apps] nshcat created branch preferences-base https://git.io/JfxvP
<_whitenotifier-f>
[scopehal-apps] nshcat created branch preferences-base - https://git.io/JvExD
<_whitenotifier-f>
[scopehal-apps] nshcat pushed 1 commit to preferences-base [+2/-0/±1] https://git.io/JfxJH
<_whitenotifier-f>
[scopehal-apps] nshcat 036c181 - Implemented Preference class
<azonenberg>
electronic_eel: I don't think i will be able to fit MII
<azonenberg>
even RMII is going to be using just about every free pin on the fpga
<azonenberg>
katharina: i'd make them a single level for now
<azonenberg>
we can support hierarchy later i guess if we see it's needed
<electronic_eel>
just add one or two more fgpas, there are enough already, a few more won't matter ;)
<electronic_eel>
I have avoided using the F7 series for RMII because of this bug yet, so I don't know how severe it is in practice
<azonenberg>
makes sense
<azonenberg>
i have rmii between the fpga and mcu on integralstick but never used it
<electronic_eel>
just wanted you to know about it beforehand
<electronic_eel>
now with the fpgas you are very flexible, so if you wanted you could provide ethernet over QSPI, packaged in your own protocol
<electronic_eel>
if the RMII shouldn't work out as planned
<azonenberg>
So my current plan is to put any higher level protocols like DHCP in gateware if i need them (static ip only to start)
<azonenberg>
then management scpi just bridged out to uart via the tcp offload
<azonenberg>
but i could easily add custom framing over that too
<azonenberg>
heck i could do raw ethernet framing over uart if i wanted :p
<azonenberg>
woop v0.9 probe board is here
<electronic_eel>
nice, now let's just hope it matches your sim more closely this time
<Katharina>
azonenberg: Do you think it would be possible to make _whitenotifier-f shut up about commits to branches other than master?
<Katharina>
i dont know how much the bot is configurable
<azonenberg>
let me see
<electronic_eel>
do you run it or does it run on whitequarks server?
<azonenberg>
The latter, but i configured it
<azonenberg>
She just hosts it for me
<azonenberg>
ah ok yeah you just need to specify a branch name, if unspecified it tracks all
<Katharina>
ah interesting
<azonenberg>
electronic_eel: there's no reason for MDIO between stm32 and fpga right?
<azonenberg>
also the stm32f7 mac apparently has 1588 support with a PPS output. so i'm gonna connect that to the fpga in case we want to do 1588
<azonenberg>
wont be as accurate as getting PPS right off a gps but might be handy to have
<Degi>
1588?
<electronic_eel>
1588 is a more accurate timing over ethernet than ntp
<monochroma>
Degi: ieee1588
<electronic_eel>
tpt
<electronic_eel>
ptp
<Degi>
neat
<electronic_eel>
but if you really want to use it, all your switches have to support it
<Degi>
oh
* monochroma
worked on some stuff long ago that iirc did 1588 over spacewire i think?
<azonenberg>
electronic_eel: my nexus supports it
<electronic_eel>
and the missing or bad support in common switches is what severely limits it. also regular pc nics usually don't have proper support
<azonenberg>
so i could use it over the 10g/40g link as is
<azonenberg>
not sure about my 1g switches
<azonenberg>
anyway its one extra gpio
<azonenberg>
if i have space i'll hook up the pin, can always not use it
<azonenberg>
RMII is now hooked up at the MCU side but i had to move one of the spi buses
<azonenberg>
working on finding a new pinout for that
<electronic_eel>
now about the MDIO, ideally you'd have to get some common phy stuff, like link up/down and so on, but I think you don't really need it or could emulate it over uart
<azonenberg>
yeah exactly my thought
<azonenberg>
also
<azonenberg>
if an IP block pin is brought out to multiple stm32 pads
<azonenberg>
is there any rule they have to be in the same bank?
<azonenberg>
for timing?
<azonenberg>
right now it looks like one set of SPI1 pins conflicts with JTAG and another with RMII, but it's not the same pins each time
<electronic_eel>
no, I don't think the stm32 banks are that tight in timing
<azonenberg>
w/e this is the spi bus to the spartan7 io expander
<azonenberg>
i can run it as slow as i like
<electronic_eel>
most times you can just select the matching alternate mode of a pin and that's it
<azonenberg>
it's just for setting Vt on each pod or checking if the pod is present
<electronic_eel>
there are very few pins that are an exception to this rule, but they are usually marked with footnotes in the pinout table
<electronic_eel>
so look out for these footnotes
<azonenberg>
ok that's pinned out, next step is to find four channels of pwm and four of tacho for the four fan headers
<azonenberg>
might not need that many but i'd rather overprovision
<electronic_eel>
do you have the fan product numbers at hand?
<electronic_eel>
not all fans like pwm
<electronic_eel>
or are they 4-pin fans with pwm-input?
<azonenberg>
But they need 5V levels on the pwm pin, not 3.3, which is annoying
<electronic_eel>
a bit thin with 15mm. with 40mm fans this means they are not very efficient
<electronic_eel>
with 40mm you usually need to get really thick fans to get some airflow
<azonenberg>
suggest a better one? not a lot of four wire fans in this size range and i wanted to pwm to keep them quiet
<azonenberg>
i wasnt expecting to need a ton of airflow but i could be wrong
<azonenberg>
i dont have a good feel for this kind of thing yet
<Degi>
Divide watts by liters per second, thats approximately the temperature rise
<electronic_eel>
also 13100 rpm will be quite loud. also means you can't lower their speed that much, something like 30% min is common for fans
<electronic_eel>
but at least you can switch them off with pwm 0
<azonenberg>
Yeah that was the plan
<azonenberg>
gate entirely when possible
<azonenberg>
the datasheet says only ~43 dBA per fan though iirc
<azonenberg>
i mean 40mm is not quiet in general
<azonenberg>
but my test rack is dense enough i think going to 2U just to use 80mm fans is ill advised
<electronic_eel>
do you see a MTBF figure somewhere in the ds?
<azonenberg>
we can of course easily re-case the system in a 2U case with 80mm fans if people want
<azonenberg>
without any pcb changes
<azonenberg>
I do not
<azonenberg>
however we have tacho so we can alarm if one dies
<azonenberg>
and the stm32 can shut down the fpgas if needed
<electronic_eel>
I have seen sooo many small fans fail
<Degi>
How much air does it push
<azonenberg>
it has full authority over all power other than 3V3_SB, 5V0_SB, and 12V0 but i can switch off basically all loads on 12V0
<Degi>
up to 0.35 m³ per min
<electronic_eel>
these are 2 ball bearing, so not too bad, but 13000 rpm is quite some speed
<Degi>
Thats 5.83 L/s
<azonenberg>
Datasheet says on page 5 they pwm down to below 5k rpm
<Degi>
At 100 W thats 17 °C temp rise
<azonenberg>
Degi: times four fans
<Degi>
why tho
<azonenberg>
Because if i have four fans i can pwm them slower
<Degi>
Then its only like 4 °C
<azonenberg>
less overall noise output and more even heating
<azonenberg>
i can always pwm some down to zero and stop them
<azonenberg>
i'd rather have flexibility
<azonenberg>
also redundancy if one ides
<azonenberg>
dies*
<Degi>
You can have one fan at 5000 RPM
<Degi>
Then you have approx 50 °C at 100 W
<azonenberg>
we don't even need to populate all four fans
<Degi>
ok
<azonenberg>
I'm providing four headers on the mainboard for flexibility
<azonenberg>
and cutouts on the pcb for four fans since i suspect i'll need to notch the board to avoid hitting them
<azonenberg>
which ones we populate is an assembly time decision
<Degi>
One fan has like 350 liters per minute heh
<azonenberg>
But yes this is why i got four wire fans
<azonenberg>
i wanted to be able to slow them down or stop entirely
<azonenberg>
also lol
<azonenberg>
here i was thinking that the stm32f777 was overkill
<azonenberg>
i'm using ethernet, every channel of I2C, two uarts, three channels of spi
<Degi>
lol
<azonenberg>
There are still, to be fair, 46 unused pins
<azonenberg>
... on a chip with 159 gpios
<azonenberg>
so i'm at 71% utilization and i will probably fan at least a few out to LEDs for debug purposes
<azonenberg>
i don't have any indicator LEDs right now
<azonenberg>
But basically every bga on this board is going to be >70% io load
<electronic_eel>
how about 603-1697-ND
<electronic_eel>
at work we used some similar fans, they worked well
<electronic_eel>
they weren't as quiet as the custom model that we ended up having manufactured for us, but until they were made we used the delta ones
<electronic_eel>
and didn't have problems with them, no defects reported within the 5 years of warranty
<azonenberg>
ooh quieter
<azonenberg>
but those are bare wires so i'd have to solder them down
<azonenberg>
a bit annoying
<electronic_eel>
no, just crimp the regular connectors on
<azonenberg>
more importantly not in stock
<azonenberg>
expected ship date October
<electronic_eel>
order now, the rest is going to take some time too
<azonenberg>
i guess i can always source another fan
<azonenberg>
if these dont come in time
<electronic_eel>
is 20mm thickness ok?
<azonenberg>
yeah should be, i'll design the pcb to allow either
<electronic_eel>
you probably want the same connectors as used in pcs?
<azonenberg>
that is the plan yes
<electronic_eel>
I can look up the part numbers for you if you don't have them at hand
<azonenberg>
I'll work on that in a bit
<azonenberg>
have some other stuff to do
<azonenberg>
but sure, look 'em up
<azonenberg>
i see molex part numbers in the original fan datasheet
<azonenberg>
for the fan side but i dont have the mate handy
<electronic_eel>
22-01-3047 is the wrong one, that is the regular kk one
<electronic_eel>
the pc fans have the polarizing rib not at the outside, but at pin 3
<electronic_eel>
that is a different pn
<electronic_eel>
now you can go with this style, it might be easier to find and source the regular kk ones
<electronic_eel>
but you can't plug in a regular pc fan then
<azonenberg>
hmmm
<electronic_eel>
now there aren't that many regular pc fans in 40mm available
<azonenberg>
yeah that was my thought
<azonenberg>
let's use what the seiko fan has on it
<azonenberg>
since that's the alternate part
<electronic_eel>
40mm tends to be special server stuff, they often have the full bldc stuff on the mainboard
<electronic_eel>
the beefy ones in dell and hpe servers
<electronic_eel>
the ones where you have to make sure your server is screwed tightly, otherwise they would start takeoff
<azonenberg>
Lol yes
bvernoux has quit [Quit: Leaving]
<_whitenotifier-f>
[starshipraider] azonenberg pushed 3 commits to master [+0/-0/±8] https://git.io/Jfxq3
<_whitenotifier-f>
[starshipraider] azonenberg 60ea7e3 - Continued design review. Added RMII pins to STM32 in case we need them. Added headers with PWM/tacho for four fans.
<_whitenotifier-f>
[starshipraider] azonenberg dff13b0 - Added four debug indicator LEDs to STM32
<_whitenotifier-f>
[starshipraider] azonenberg cbfc203 - Added RMII connections to FPGA
<azonenberg>
ok so lets see, MCU now has 42/159 unused so 74% IO used
<azonenberg>
the spartan7 has 28/100 unused so 72% used
<azonenberg>
and not counting transceivers, the kintex7 has 32/400 unused so 92% used
<azonenberg>
electronic_eel: do you think i should add indicator LEDs to each pod on the host side, to show i detected/powered the pod?
<azonenberg>
i dont see it being necessary, but it occurred to me as a possibility